Redes de Circuitos Dinâmicos na RNP

Apresentação em tema: "Redes de Circuitos Dinâmicos na RNP"— Transcrição da apresentação:

1 Redes de Circuitos Dinâmicos na RNP
Treinamento para participantes do Serviço Experimental Cipó

2 Agenda Redes de Circuitos Dinâmicos
Motivação e adoção por outras NRENs Modelo de arquitetura Softwares usados no plano de controle A rede híbrida da RNP e o SE-Cipó Treinamento com foco no SE-Cipó

3 DCN e Rede Híbrida DCN: Dinamic Circuit Network
Comutação de circuitos com provisionamento automático (mais uma vez...) Por ser circuito, pressupõe-se: Caminho de rede único pré-determinado por sinalização Banda garantida ao longo do caminho Porém, solução (genérica) deve contemplar: Múltiplos domínios administrativos Independência da tecnologia de rede

4 DCN e Rede Híbrida Rede híbrida (para nós): DCN + Rede de pacotes
Garante requisitos de banda fim-a-fim através do provisionamento dinâmico de circuitos Sobre múltiplos domínios, independente da tecnologia de rede usada por cada domínio Domínio: região sob uma mesma administração de rede Pode ser um AS Pode ser uma rede de campus

5 Motivação para uso de DCN
Modelo roteado não fornece tais garantias: Não há como definir arquitetura de QoS fim-a-fim sobre múltiplos domínios A quem se destina (maiores usuários)? Aplicações que precisam transferir grandes volumes de dados  Grids, previsão climática, e-ciência etc Fluxos com fortes requisitos de QoS (perda, jitter) Tempo de transferência é crítico Virtualização de redes Fazendo uso de camadas abaixo do IP, p/ex.

6 Tráfego de dados na ESnet
TB/mês [Johnston 2011], destaque para Fermilab (FNAL): Laranja: tráfego de circuitos Azul: tráfego IP Vermelho: top-1000 fluxos IP Amarelo: fluxos usando circuitos dinâmicos a partir de Jan/2010

7 LHC - Large Hadron Collider
Acelerador de partículas do CERN localizado na Suíça

8 LHC - Large Hadron Collider
27Km de circunferência Dados gerados são processados ao redor do globo Boa parte dos circuitos dinamicamente criados na ESnet estão relacionados com o LHC

9 Compact Muon Solenoid (CMS) Grid
[Jonhston 2011]

10 WLCG – Worls LHC Computing Grid
[Barczyk 2011]

11 Transferência de dados
Bases de dados da ordem de TBytes são cada vez mais comuns Tempo para transferir 1TB [Dart 2010]: 10 Mbps: 300 hrs (12,5 dias) 100 Mbps: 30 hrs 1 Gbps: 3 hrs (discos "rápidos" o bastante?) 10 Gbps: 20 min (discos e filesystems precisam ser muito rápidos!)

12 Transferência de dados
Tempo para mover Y Bytes num tempo X:     Disponível em 

13 Além da garantia de banda
Controle de congestionamento do TCP Reno reduz o aproveitamento da banda disponível Implementações TCP turbinadas (disponíveis no Linux): Cubic, HTCP, Bic, Vegas etc Buffers do TCP precisam ser aumentados Auto-tuning de buffers (transmissor e receptor) Disponível na maioria dos SOs Aplicações também precisam ser "espertas": Ex.: GridFTP

14 Por que ser dinâmico? Configuração manual de circuito muito custosa
Tempo de set-up grande, principalmente para circuito multidomínio Várias interações entre operadores, compatibilização de tecnologias de rede etc  Não escala Transferências ocorrem sob demanda Circuitos não devem ficar alocados todo o tempo Uso racional de recursos

15 Circuitos dinâmicos Solução deve contemplar criação e remoção automáticas de circuitos mediante agendamento Por operadores, usuários e/ou aplicações Necessário definir políticas para tal Solução dinâmica se torna escalável Permite uma grande quantidade de circuitos sendo automaticamente configurados Dor de cabeça para a gerência? Boa parte dependerá da arquitetura Processos e ferramentas de gerenciamento devem estar adaptados à nova realidade

16 Exemplos de NRENs usando DCN
USA: ESnet e Internet2 Canada: CANARIE Europa: GEANT e diversas redes europeias (SURFnet, NORDUnet, ) Asia: Coréia (KOREN) e Japão (JGN2) Ampath: primeiras experiências c/ rede híbrida (p/ GLIF meeting 2011, Rio) etc

17 Global Lambda Integrated Facility (GLIF)
[Tanaka 2009] GOLE: GLIF Open Lightpath Exchange

18 Modelo de arquitetura para DCN
Vários desafios: Aspectos multidomínio, diferentes tecnologias de rede, controle de admissão, agendamento etc A serem destacados: Negociação multidomínio Equipamentos s/ suporte a circuito virtual Efetivação da reserva de recursos ao longo do caminho Arquitetura genérica contempla os desafios em destaque

19 Modelo de arquitetura para DCN
Arquitetura genérica usa o conceito de plano de controle e plano de dados Plano de controle: Protocolos e SW que definem o encaminhamento dos pacotes Plano de dados: Faz o encaminamento dos pacotes conforme definido pelo plano de controle Em geral, ambos os planos residem no mesmo equipamento, mas podem estar separados: Plano de controle rodando fora dos equipamentos que fazem o encaminhamento dos dados Permite um mesmo SW controlando toda a rede

20 Plano de controle na arquitetura DCN
Solução para plano de controle se divide em interdomínio (IDC) e intradomínio (DC) [DCN 2008]

21 Plano de controle na arquitetura DCN
Controle intradomínio cuida da configuração e remoção dos circuitos nos equipamentos num dado domínio Dependente da tecnologia de rede Papel do DC (Domain Controller) Controle interdomínio cuida da negociação do circuito entre domínios vizinhos Deve ser independente da tecnologia de rede Sinaliza as ações de controle para o intradomínio Papel do IDC (Inter-Domain Controller)

22 Detalhes de uma arquitetura DCN
[Tanaka 2009]

23 Softwares adotados Principais SWs para controle interdomínio:
OSCARS (Esnet, Internet2, RNP etc) AutoBAHN (GEANT) UCLP (CANARIE) Principal SW para controle intradomínio DRAGON SWs para front-end de gerenciamento: ION (Internet2) MEICAN (RNP) Interfaces web dos SWs de IDC

24 Rede híbrida da RNP Rede Cipó: futura rede híbrida da RNP
SE-Cipó: Serviço Experimental com foco na rede Cipó Potencial de uso: Transferências de dados para computação em grade HepGrid (UERJ), Sprace (UNESP) Transmissão de vídeo 4K (CineGRID, CPqD) Espetáculos de dança interativa Telemedicina etc

25 Arquitetura do SE-Cipó
Topologia descentralizada Diversos domínios OSCARS instalados nos PoPs Mas com alguns elementos centralizados: Um OSCARS instalado no backbone Somente uma instalação do perfSONAR Somente uma instância do sistema MEICAN gerenciando todos os domínios

26 Arquitetura do SE-Cipó
O backbone da RNP – rede Ipê – se consistirá num único domínio Fronteiras do domínio coincidem com a fronteira administrativa, ou seja, até as interfaces para os equipamentos de distribuição do PoPs Clientes dos PoPs farão parte de um domínio separado É possível que outros domínios surjam ligados ao domínio PoP: Instituições ou redes metropolitanas, p/ex.

27 Topologia do SE-Cipó Um OSCARS também no backbone, e somente uma instância do MEICAN

28 Mais sobre o SE-Cipó Testes interdomínio com Internet2 foram realizados na reunião do GLIF 2011 no Rio Há um grupo na RNP trabalhando na seleção de potenciais usuários do serviço, além dos já conhecidos Esforço para criar processos de operação do backbone (Gerência de Operações) aderentes ao novo “paradigma” Comentar sobre a monitoração

29 Mais sobre o SE-Cipó Prazo alvo para efetivação do serviço no 1º semestre de 2012 GTs estão envolvidos com o desenvolvimento do serviço nas áreas estratégicas: Arquitetura (ligação do OSCARS aos roteadores do backbone) Documentação e geração de templates para configuração de clientes Monitoramento Gerenciamento via MEICAN Weathermap Comentar sobre a monitoração

30 Treinamento com foco no SE-Cipó
É previsto treinamento para técnicos e gestores envolvidos com o serviço experimental Técnicos dos PoPs, de instituições clientes e de laboratórios usuários 1ª realização no SCI 2011, sendo elencado para nova oferta no SCI 2012 Utilização de infraestrutura remota de laboratório Hospedada na UNIRIO, em fase de ativação Comentar sobre a monitoração

31 Treinamento com foco no SE-Cipó
AGENDA Segunda Terça Quarta Quinta Sexta Manhã (4h) + break Introdução, agenda Dragon (intro.) OSCARS (intro., instal.) MEICAN (intro.,config.) SE-Cipó Break Tecnologias de redes híb. Dragon (instal., config.) OSCARS (config. intrad., testes) MEICAN (config., uso) Discussões Almoço Tarde (2h) Testes da infra., lab. de QinQ Dragon (testes) OSCARS (conf. interd., testes) Monitoramento

32 Lay-out do laboratório
POD: conjunto de 2 switches e um servidor Switches são Extreme ou Cisco Servidor é Dell com SO base VMware ESXi Cada POD representa um domínio: Servidor abriga VMs do plano de controle e VMs de clientes VMs de clientes e switches representam plano de dados Topologia possui 4 PODs dispostos em anel + servidor extra para abrigar serviços centrais

33 Topologia lógica

34 Topologia física

35 Instalação física

36 Atividades práticas Lay-out do laboratório Plano de endereçamento
Testes de acesso a VMs e switches Testes de conectividade Verificação de softwares instalados Verificação da configuração base dos switches Acompanhamento da instalação do Dragon Configuração do Dragon e teste intradomínio

37 Atividades práticas Acompanhamento da instalação do OSCARS
Configuração do OSCARS para intradomínio e testes Configuração do OSCARS para interdomínio e testes Acompanhamento da instalação do MEICAN Configuração do MEICAN e testes intra e interdomínio Uso de ferramentas de monitoramento

38 Obrigado! sidney@uniriotec.br

39 Slides de BACKUP

40 Arquitetura do SE-Cipó
No domínio da rede Ipê não haverá uso de Dragon Roteadores de núcleo são capazes de fazer MPLS e rodar OSPF-TE e RSVP-TE Mesma abordagem atualmente usada pela ESnet e pela Internet2 Domínio do PoP fará uso de Dragon Configuração dos switches de distribuição, etc Provavelmente o mesmo nos domínios clientes Maioria dos clientes deve se ligar c/ VLAN estática

41 Arquitetura do SE-Cipó
O que a RNP fará que ninguém mais tentou fazer ainda (até onde sabemos): Usar os Logical Systems dos Junipers MX para “virtualizar” a DCN Logical System é como a Juniper chama sua funcionalidade de roteador virtual (“virtual router” é uma forma mais simplificada disto) Ideia é garantir isolamento da rede IP de produção

42 Arquitetura do SE-Cipó
Uso de logical systems: Interligações entre logical systems através da VLAN 3200 configurada nas interfaces físicas Policiamento a 1 Gbps na VLAN 3200 do enlace, ambos sentidos Por enquanto sem reserva de banda Tráfego IP de produção pode “invadir” banda dos circuitos MPLS, LDP e RSVP habilitados nas interfaces WAN do backbone

43 Arquitetura do SE-Cipó
Uso de logical systems: Acesso para clientes previsto apenas nos PoPs RS, SC, PR, SP, RJ e PA Padronizado usar porta ge-2/3/4, sem endereço IP aplicado Mais uma interface de acesso em RJ e SP: No RJ, a xe-3/0/ para acesso ao OSCARS da Rede Ipê Em SP, a ge-2/3/3 para falar com Ampath Faixas IPv4 e IPv6 p/ interfaces da VLAN 3200

44 Arquitetura do SE-Cipó
OSCARS da rede Cipó: Servidor da aplicação instalado no escritório da RNP no Rio Acesso do OSCARS aos equipamentos via SSH Configuração dos equipamentos via junoscript Usuário “oscars” configurado nos Log.Sys. Permissão de configuração apenas nestas instâncias Somente as interfaces ge-2/3/4 podem ser configuradas (ge-2/3/3 no caso de SP)

45 Arquitetura do SE-Cipó
Topologia lógica:

46 Arquitetura do SE-Cipó
Topologia física + lógica:

47 Arquitetura do SE-Cipó
Problemas identificados: SNMP não faz distinção dos Log. Sys., enxerga apenas a caixa (problemas foram contornados) OSCARS compilado para falar junoscript não fala com Dragon e vice-versa Problemas com “configurate private” do Juniper: Se algum operador usar este comando, OSCARS não consegue configurar o equipamento Lixo de configuração nos Log. Sys, qdo circuito não é estabelecido (remoção manual)