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

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ó

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

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

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.

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

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

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

Compact Muon Solenoid (CMS) Grid [Jonhston 2011]

WLCG – Worls LHC Computing Grid [Barczyk 2011]

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

Transferência de dados Tempo para mover Y Bytes num tempo X:     Disponível em http://fasterdata.es.net/fasterdata/requirements-and-expectations/

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

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

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

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

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

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

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

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

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)

Detalhes de uma arquitetura DCN [Tanaka 2009]

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

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

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

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.

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

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

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

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

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

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

Topologia lógica

Topologia física

Instalação física

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

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

Obrigado! sidney@uniriotec.br

Slides de BACKUP

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

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

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

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/0.3250 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

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)

Arquitetura do SE-Cipó Topologia lógica:

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

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)