casos de uso do perfsonar

Monitoração de Desempenho de RedesCurso SCI/RNP

http://wiki.monipe.rnp.br

16º Seminário RNP de Capacitação e Inovação | 18 a 22 de outubro de 2010 | Curitiba - PR

Casos de Uso do perfSONAR

José Augusto Suruagy Monteiro

Baseado em slides do Jeff Boote (Internet2)


2

• Motivação• Como Deve funcionar• Como Provavelmente funciona• Identificação de problemas de rede comuns• Casos de Uso– Campus Internacional da Georgetown– USAtlas


3

• Agora que vimos a finalidade e a composição da infraestrutura do perfSONAR, devemos ver o que ele pode fazer no mundo real

• O perfSONAR é usado por engenheiros de rede para identificar diversos tipos de problemas de desempenho– É necessária uma estratégia de dividir para conquistar para isolar os

problemas– Uma metodologia estruturada ajuda a eliminar passos duplicados ou

desnecessários– perfSONAR funciona melhor quando todos participam, lacunas na

implantação leva a lacunas na fase de resolução do problema• As seções seguintes irão ilustrar a estratégia correta de

implantação e apresentar alguns casos de uso reais

Motivação


4

• Para endereçar acuradamente e corretamente os problemas de desempenho de rede, devem ser tomados os seguintes passos:– Identificar o problema: se um usuário em uma localidade estiver

reclamando do desempenho em outra localidade, obtenha a maior quantidade de informação possível• O problema ocorre em apenas um sentido, ou em ambos os sentidos?• O problema ocorre sempre, frequentemente ou raramente?• O problema ocorre apenas para uma aplicação específica, para diversas

aplicações, ou apenas para algumas aplicações?• O problema é reproduzível em outras máquinas?

– Reúna informação sobre o ambiente• Hospedeiros• Caminho da rede• Configuração (onde for aplicável)• Recursos disponíveis

Como Deve funcionar


5

• Cont.:– Aborde o problema metodicamente

• Realize testes usando a mesma ferramenta em todo lugar, reúna os resultados• Antes de passar para a próxima ferramenta, você reuniu tudo o que era

valioso?• Os resultados estão consistentes?

– Após utilizar todas as ferramentas e abordagens, forme teorias• O problema pode ser isolado a um recurso ou componente específico?• Podem ser realizados testes para eliminar pontos mortos?

– Considere o seguinte exemplo:• Caminho internacional• Problemas observados• Conhecemos o caminho• Temos ferramentas disponíveis

Como Deve funcionar


6

Cenário: Caminho internacional multidomínio


7

Caso desejável: Desempenho esperado


8

Caso Típico: Desempenho pobre...

Em algum lugar!


9


Em algum lugar!

Mas onde?


10

Solução: Pontos de Teste + Monitoração Regular


11

perfSONAR: Rede Troncal e Pontos de Troca


12

perfSONAR: Redes Regionais


13

perfSONAR: Campus


14

Decomposição do Caminho – Isolar o problema

Passo a passo: teste entre os pontos


15


1o segmento – não foi encontrado nenhumproblema


16


2o segmento – Problemaidentificado


17


2o segmento – ProblemaIdentificado… e resolvido!


18


Mas, o desempenho fim-a-fim ainda estáruim!


19


3o segmento – Sem problemas


20


4o segmento – Sem problemas


21


5o segmento – últimoproblema encontrado…


22


5o segmento – últimoproblema encontrado…e resolvido!


23

• A resolução dos problemas requer ferramentas adequadas– Especializadas para uma determinada tarefa (ex., largura de

banda, latência)– Largamente disponíveis onde possam existir problemas

• Isolar um problema é um processo bem definido, de diversos passos– Conjunto rígido de passos – abordagem sistemática para

evitar causar novos problemas• Diagnósticos, assim como a monitoração regular, podem

revelar a verdadeira natureza do desempenho da rede

Lições Aprendidas


24

• Se os passos sugeridos não forem seguidos (ou forem seguidos de forma aleatória), os resultados podem variar.– Saltar passos leva à falta de pistas

• Implantação e participação pode variar, isto leva a algumas lacunas no processo de depuração

• Considere o seguinte exemplo:– Caminho internacional

• Caminho internacional• Problemas observados• Conhecemos o caminho• Temos ferramentas disponíveis – quase em toda parte

Como Provavelmente funciona


25

Cenário: Caminho Internacional Multidomínio


26

Caso desejável: Desempenho esperado


27


Em algum lugar!


28


Em algum lugar!

Mas onde?


29



30


Ponto chave: monitoração fim-a-fimrequer participação de todos osdomínios


31


Em algum lugar!

Internet2 – disponívelna rede troncal


32


Em algum lugar!

Os Campus também estão participando


33


Em algum lugar!

Os pontos de trocadisponibilizam as estatísticas


34


Em algum lugar!

Uma rede regional podenão participar…


35


Em algum lugar!

Não é possível uma monitoração fim-a-fimcompleta.


36

• A lacuna no caminho deixa-nos com uma grande desvantagem

• Pode descobrir alguns problemas através de isolamento no caminho que conhecemos, mas podemos deixar algo de lado– Muitos problemas de rede ocorrem na demarcação

entre duas redes– Testar ao redor do problema não resolverá (ainda

teremos que trafegar por esta rede)

Lições Aprendidas


37

• Diferentes requisitos– A rede do campus não é projetada para grandes fluxos

• Requisitos corporativos• São comuns centenas de Mbits, algo a mais é raro (ou visto como estranho)• Firewalls• A rede é projetada para mitigar os riscos dado que o hardware comum (desktops e laptops)

não são confiáveis– Ciência é diferente

• A rede necessita ser robusta e estável (desempenho previsível)• Dezenas de Gbits de tráfego (Provavelmente não é contínua – mas poderia ser)• Sensível às proteções corporativas (firewalls, projeto da LAN)

• Consertar não é fácil– Projete a rede básica para ciência, acrescente a corporativa ao lado (caro, consome

tempo , e boa sorte para convencer o seu campus de que isto é necessário...)– Mitigue os problemas movendo o seu equipamento de ciência para a borda

• Tente desviar do firewall a todo custo• Chegue o mais perto da conexão da WAN quanto for possível

Por que o Movimento de Dados Científicos é diferente?


38

• Os exemplos anteriores pintam uma visão geral: há um problema, em algum lugar, que precisa ser consertado

• O que pode estar lá fora?– Arquitetura– Problemas comuns, ex., “Falhas Leves”

• Mitos e Armadilhas– É fácil cair em armadilhas– Também é fácil seguir falsas pistas

Identificando Problemas Comuns de Rede


39

• Questão: Você reclamaria se você soubesse que o que você está recebendo não está correto?

• Nota: o desempenho real entre a Vanderbilt University e TACC deveria ser de cerca de 1Gbps em ambos os sentidos.



40

• Os engenheiros de rede ajudarão os membros e usuários a depurar problemas que chegarem até eles– O objetivo é resolver todo o problema – fim a fim– Envolve muitos atores (tipicamente: usuários finais, pessoal de rede do

Campus, Regional e Troncal)– Processo lento de localização e teste de cada segmento no caminho– Utilizar ferramentas que facilitem o trabalho (mas sobre isto

posteriormente)• Emergem temas e padrões comum praticamente para cada

exercício de depuração– Arquitetura (ex., projeto da LAN, escolha do equipamento, Firewalls)– Configuração– “Falhas Leves”, ex. algo que não interrompe a conectividade, mas torna a

experiência desagradável



41

• Projeto de LAN vs. WAN– Fluxos de múltiplos Gbits (para fora) deveriam estar próximos à conexão de

WAN– Elimine o número de etapas/dispositivos/cabos que podem lhe atrasar– Ótimo desempenho na LAN != ótimo desempenho na WAN

• Você Recebe por aquilo que pagou– Equipamento barato lhe deixará na mão– Rede

• Pequenos buffers, desempenho questionável (ex. matriz de comutação interna não consegue acompanhar a demanda da LAN e muito menos a da WAN)

• Falta de ferramentas de diagnóstico (SNMP, etc.)– Armazenamento

• A vazão do disco precisa ser grande o bastante para enviar tudo para a rede• Jogar um montão de disco num servidor deficiente também não é bom

– Desempenho do barramento– Cartões de rede

Considerações Arquiteturais


42

• Firewalls– Projetado para interromper o tráfego

• Leia isto lentamente algumas vezes...– Buffers pequenos

• Preocupação em proteger a rede, sem se preocupar como desempenho

– Será bem mais lento que a velocidade de linha original– Um “Firewall de 10G” pode manipular um fluxo próximo a

10G, mas não conseguirá manipular alguns fluxos a mais.– Se for importante uma funcionalidade do tipo firewall –

considere usar filtros nos roteadores

Considerações Arquiteturais


43

• Configuração do hospedeiro– Ajuste os seus hospedeiros (especialmente

computação/armazenamento!)– Mudanças em diversos parâmetros podem levar a uma melhora entre 4

a 10X– Leva alguns minutos para implementar/testar– Instruções: http://fasterdata.es.net/tuning.html

• Configuração do Switch/Roteador– Configuração padrão (ao tirar da caixa) podem incluir buffers pequenos– Objetivos competidores: vídeo/áudio necessitam pequenos buffers para

manter a interatividade. Os fluxos de ciência necessitam de grandes buffers para enviar mais dados para a rede.

– Leia os seus manuais e execute um teste de um hospedeiro numa LAN para um hospedeiro numa WAN para verificar (e não LAN paraLAN)

Configuração

http://fasterdata.es.net/tuning.html


44

• Configuração do hospedeiro – identifique quando as configurações foram mexidas ...

• NOTA: Exemplo extraído da REDDnet (Umich para TACC), usando medições BWCTL.

Configuração – cont.


45

• Falhas Leves são qualquer problema de rede que não resulta em uma perda de conectividade– Reduz a velocidade de uma conexão– Difícil de ser diagnosticada e encontrada– Pode passar desapercebida pelos usuários da LAN em alguns

casos, mas os usuários remotos podem ser quem irá reclamar• Alerta – quanto tempo/energia você gasta escutando a reclamações de

usuários remotos?– Comum:

• Cabos sujos ou dobrados• Interfaces/óptica com problemas• Comutação do processo [Roteador] (punting)• Configuração do roteador (buffers/filas)

Falhas Leves


46

• Cabos sujos ou dobrados e Interfaces/Óptica com defeito– Provoca baixos níveis de perdas – pode não ser notado em uma

LAN, será notado na WAN– Será detectado com ferramentas passivas (ex. monitoração

SNMP)– Pergunta: você o consertaria se soubesse que estava quebrado?

• Comutação de Processo [Roteador]– “Chuta” o tráfego para um caminho mais lento

• Configuração do Roteador (Buffers/Filas)– Deve ser grande o bastante para acomodar fluxos científicos– Esgotamento da tabela de overflow (o sistema se dirige para

uma parada quando a memória estiver esgotada)

Falhas Leves – cont.


47

• A identificação e o conserto devem ser realizados através do uso de ferramentas de monitoração e de diagnóstico– Identifique pontos de testes na rede

• Nas bordas e no centro– Teste os pontos da WAN para encontrar problemas difíceis de serem

diagnosticados• Onde colocar e como encontrá-lo

– Peça a seus colaboradores para alocar de forma comum uma máquina de teste– Use ferramentas de descoberta para encontrá-las (ex. perfSONAR)

– Use um leque de ferramentas para características diferentes• Latência (um sentido e ida-e-volta)• Largura de banda• Utilização/Descarte/Erros da interface• Testes ativos vs. passivos

Falhas Leves – cont.


48

• “O desempenho da minha LAN está perfeito, o desempenho da WAN é provavelmente o mesmo”– O TCP recupera de perdas e congestionamento mais rapidamente na LAN (baixo RTT)– O TCP corta a velocidade pela metade para cada perda/descarte na WAN – levará um bom

tempo para recuperar no caso de grandes RTTs.– Pequenos níveis de perda na LAN (ex. 1/1000 pacotes) passarão desapercebidos, mas

serão muito evidentes numa WAN.• “O ping não está mostrando as diferenças de perdas e latência”

– O ICMP pode ser bloqueado/ignorado por alguns sítios– Os roteadores processam ICMP de uma forma diferente da de outros pacotes (ex. pode

apresentar atraso fantasma).– O ICMP pode esconder algumas (mas não todas) as perdas– Não mostrará atrasos de roteamento assimétricos (ex. tomando um caminho diferente

para transmitir e para receber)• O nosso objetivo é desmentir este e outros ensinando o caminho adequado para

verificar a rede – temos muitas ferramentas à nossa disposição, mas é necessário também usá-las na ordem correta.

Mitos e Armadilhas


49

• Os seguintes casos de uso demonstram o uso das ferramentas do perfSONAR para resolver alguns problemas de desempenho complexos– Telepresença da CISCO:

• Caminho multidomínio onde as garantias de desempenho ditam o uso de uma aplicação específica

– Campus Internacional da Georgetown• Garantindo a qualidade de um lado do mundo para o outro

– USAtlas• Permite a Grande Ciência através de verificações de diagnóstico e uma

monitoração regular– REDDnet

• Garantia de caminhos limpos para a movimentação dos dados.

Casos de Uso


50

Caso de Uso - Georgetown


51

• Campi da Georgetown University– Washington DC, EUA– Doha, Qatar

• Rede de acesso mantida entre os dois campi– Provida pela Qatar Foundation Network– Interconecta com a Internet2 em Nova Iorque (Ponto

de troca MANLAN)• Objetivo: fornecer áudio e vídeo de alta qualidade

para educação a distância entre os dois sítios.

Campus Internacional da Georgetown


52

• Definição do problema– Problemas intermitentes de rede têm afetado o vídeo– O pessoal local de TI pediu ajuda na análise do

desempenho – antes e depois de um upgrade na rede• Solução de Monitoração de Desempenho– Ferramentas perfSONAR (OWAMP) para a analisar a

conexão– Pessoal da Internet2 ajudou na instalação,

configuração e análise



53

• Caminho da Rede– Georgetown (Washington) para MAX (Rede Regional)– MAX para a rede troncal da Internet2– Internet2 (MANLAN) para a Rede da Qatar Foundation

(QF)– Rede da Qatar Foundation para Georgetown (Doha)

• Monitoração proposta– 1º passo: Nova Iorque até Doha– Foi instalado e configurado o OWAMP para testes

regulares



54

• Nova Iorque para Doha (Jitter observado)



55

• Doha para Nova Iorque (Jitter observado)



56

• Interpretação– Congestionamento no enlace (compartilhado) da QF– Observado entre 0:00 e 8:00 (EST)– O congestionamento causou perdas esporádicas e jitter –

mas ainda dentro dos limites para permitir algumas formas de vídeo e de áudio

• Observações de roteamento– Todo o tráfego a partir de Doha parece retornar através

da MANLAN– Isto causa anormalidades de medições (ex.: sincronismo

do relógio é afetado pelo atraso da rede)



57

• Desempenho observado do NTP



58

• Interpretação– O NTP (Network Time Protocol) tem dificuldades em se

ajustar ao atraso da rede– Mudanças no roteamento podem corrigir este

comportamento• Status atual– Completado o 1º estágio de testes– Esperando o upgrade do enlace antes de iniciar o 2º

estágio de testes– Será analisada a expansão da monitoração para outras

partes do caminho



59

Caso de Uso - USAtlas


60

• Em 2007 a USATLAS decidiu como grupo avaliar a 2ª geração do CD do perfSONAR (NPToolkit) como arcabouço para testes e monitoração

• Cada instalação de Tier 2 e Tier 1 adquiriu 2 servidores– “Koi Computers” – Chassis de 1U– Processador Pentium Dual Core com 2,2GHz– 2GB de RAM– HD de 160GB– ~$1200 para os dois



61

• Em 2009 todos os sítios ainda utilizam o hardware original, rodando a 3ª geração (3.1 e 3.1.1) do pS-PT (Caixa de ferramentas de desempenho)

• Testes– BWCTL

• Testes em malha completa entre todos os Tier2 e Tier1• Testes de largura de banda de 20s a cada 4 horas• Pode ajustar o agendamento baseado na quantidade de dados observados como de

medições– OWAMP

• Testes em malha completa entre todos os Tier2 e Tier1• Fluxos contínuos de 1 minuto de teste de OWAMP (10 pacotes por segundo – 600 por

minuto)• Determina a latência min/máx, perda e jitter (variação do atraso)

– PingER• Não obrigatório – mas deveria testar em “malha completa” para todos os Tier2 e Tier1



62

• Alocação das máquinas– 2 por sítio– Instalada próximo a outros equipamentos Tier2 (com

temperatura controlada e próxima aos equipamentos da WAN)– Servidor de teste de latência

• Testes com o OWAMP• Testes com o PingER• Monitoração SNMP

– Servidor de teste de largura de banda• Testes do BWCTL• Diagnósticos com NDT• Diagnósticos com NPAD



63

• Procedimentos– Leva cerca de 2 semanas para atualizar quando sai uma nova

versão ISSO– 1 a 2 semanas para estabelecer os parâmetros de testes iniciais e

configurar os testes regulares• Instala antes as “caixas” de modo que possam ser “encontradas” pelas

ferramentas do perfSONAR• Configura as malhas de teste (cada sítio realiza testes para todos os

demais)– Teleconferência semanal (muitas vezes com um engenheiro da

Internet2/Esnet) para avaliar o desempenho que está sendo observado e para pedir melhorias + relato de bugs da ferramenta

– Cada sítio irá coordenar com outros para depurar problemas identificados



64

• Usos– Dados regulares do BWCTL/OWAMP são vistos

diariamente pelos administradores do sítio e da USAtlas em busca de anormalidades

– Usado em conjunto com os dados do GridFTP e outras formas de testes de vazão

– Ferramentas de diagnóstico (NPAD/NDT) são usados por participantes Tier2 e Tier3 para diagnosticas problemas do sítio final para os repositórios de dados do USAtlas



65

• Problemas encontrados– Problema de vazão entre Tier1 e Tier2

• Não conseguia passar de 1 Gbps num caminho de 10 GbE que incluía 5 domínios administrativo

• Usou ferramentas do perfSONAR para localizar o problema• Identificado o dispositivo problemático

– Um domínio não relacionado havia vazado uma tabela de roteamento completa por um curto tempo causando corrupção da FIB. O problema de roteamento foi corrigido, mas o roteador começou a comutar o processamento após alguns fluxos.

• Correção– A reinicialização do dispositivo corrigiu os sintomas do problema– Melhores filtros BGP naquele parceiro irá prevenir a recorrência (desta causa para esta

classe de falhas leves)

– Eventos de perdas para um Tier 2 específico• Forneceu uma razão rápida para problemas de largura de banda persistentes• Foi corrigido rapidamente depois que houve prova das perdas



66

• Futuro– Preocupação com os Tier3s – avaliação da nova versão

do pS-PT antes de recomendá-lo– Os Tier3 podem não querer usar 2 servidores• Adquirir pelo menos um para diagnósticos – testes

ocasionais– Os Tier3 não irão realizar testes em malha completa

com os Tier2 e Tier3 (tráfego excessivo)– As máquinas KOI podem ser substituídas por

hardware equivalente



67

• Ferramentas de desempenho são mais do que capazes de ajudar a diagnosticar e corrigir problemas de rede

• O sucesso depende de diversos fatores– Implantação completa– Metodologia consistente– Paciência!

• Os casos de uso apresentados realçam temas comuns• Estes não serão os últimos problemas de

desempenho que resolveremos

Conclusão

Monitoração de Desempenho de RedesCurso SCI/RNP

http://wiki.monipe.rnp.br


Casos de Uso do perfSONAR

José Augusto Suruagy Monteiro

Baseado em slides do Jeff Boote (Internet2)

casos de uso do perfsonar

Documents

br16 seminrio rnp

problemas de desempenho

desempenho pobre

prn perfsonar

desempenho necessria

problema reproduzvel

teoriaso problema

prn soluo