Casos de Uso do perfSONAR

1. 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. Motivação • 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 estruturadaajuda 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

4. Como Deve funcionar • 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

5. Como Deve funcionar • 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

6. Cenário: Caminho internacional multidomínio

7. Caso desejável: Desempenho esperado

8. Caso Típico: Desempenho pobre... Em algum lugar!

9. Caso Típico: Desempenho pobre... Masonde? Em algum lugar!

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 ospontos

15. Decomposição do Caminho – Isolar o problema 1osegmento – nãofoi encontradonenhum problema

16. Decomposição do Caminho – Isolar o problema 2osegmento – Problema identificado

17. Decomposição do Caminho – Isolar o problema 2osegmento – Problema Identificado… e resolvido!

18. Decomposição do Caminho – Isolar o problema Mas, o desempenho fim-a-fimaindaestá ruim!

19. Decomposição do Caminho – Isolar o problema 3osegmento – Sem problemas

20. Decomposição do Caminho – Isolar o problema 4osegmento – Sem problemas

21. Decomposição do Caminho – Isolar o problema 5osegmento – último problemaencontrado…

22. Decomposição do Caminho – Isolar o problema 5osegmento – último problemaencontrado… e resolvido!

23. Lições Aprendidas • 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

24. Como Provavelmente funciona • 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

25. Cenário: Caminho Internacional Multidomínio

26. Caso desejável: Desempenho esperado

27. Caso Típico: Desempenho pobre... Em algum lugar!

28. Caso Típico: Desempenho pobre... Em algum lugar! Masonde?

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

30. Solução: Pontos de Teste + Monitoração Regular Ponto chave: monitoraçãofim-a-fim requerparticipação de todosos domínios

31. Caso Típico: Desempenho pobre... Em algum lugar! Internet2 – disponível naredetroncal

32. Caso Típico: Desempenho pobre... Em algum lugar! Os Campus também estãoparticipando

33. Caso Típico: Desempenho pobre... Em algum lugar! Os pontos de troca disponibilizam as estatísticas

34. Caso Típico: Desempenho pobre... Em algum lugar! Umarede regional pode nãoparticipar…

35. Caso Típico: Desempenho pobre... Em algum lugar! Não é possíveluma monitoraçãofim-a-fim completa.

36. Lições Aprendidas • 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)

37. Por que o Movimento de Dados Científicos é diferente? • 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

38. Identificando Problemas Comuns de Rede • 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

39. Identificando Problemas Comuns de Rede • Questão: Você reclamaria se você soubesse que o que você está recebendo não está correto? • Nota: o desempenho real entre a VanderbiltUniversity e TACC deveria ser de cerca de 1Gbps em ambos os sentidos.

40. Identificando Problemas Comuns de Rede • 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. Considerações Arquiteturais • 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

42. Considerações Arquiteturais • 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 maislento 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

43. Configuração • 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)

44. Configuração – cont. • Configuração do hospedeiro – identifique quando as configurações foram mexidas ... • NOTA: Exemplo extraído da REDDnet (Umich para TACC), usando medições BWCTL.

45. Falhas Leves • 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)

46. Falhas Leves – cont. • 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)

47. Falhas Leves – cont. • 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

48. Mitos e Armadilhas • “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.

49. Casos de Uso • 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.

50. Caso de Uso - Georgetown