Redes de Circuitos Dinâmicos na RNP Treinamento para participantes do Serviço Experimental Cipó
Transcript of Redes de Circuitos Dinâmicos na RNP Treinamento para participantes do Serviço Experimental Cipó
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 Networko Comutação de circuitos com provisionamento
automático (mais uma vez...)
• Por ser circuito, pressupõe-se:o Caminho de rede único pré-determinado por
sinalizaçãoo Banda garantida ao longo do caminho
• Porém, solução (genérica) deve contemplar:o Múltiplos domínios administrativoso Independência da tecnologia de rede
DCN e Rede Híbrida
• Rede híbrida (para nós): DCN + Rede de pacoteso 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ínioo 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:o Não há como definir arquitetura de QoS fim-a-fim sobre
múltiplos domínios
• A quem se destina (maiores usuários)?o 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
o Virtualização de redeso Fazendo uso de camadas abaixo do IP, p/ex.
Tráfego de dados na ESnet
• TB/mês [Johnston 2011], destaque para Fermilab (FNAL):
Vermelho: top-1000 fluxos IPAmarelo: fluxos usando circuitos dinâmicos a partir de Jan/2010
Laranja: tráfego de circuitosAzul: tráfego IP
LHC - Large Hadron Collider
• Acelerador de partículas do CERN localizado na Suíça
LHC - Large Hadron Collider
• Dados gerados são processados ao redor do globo• Boa parte dos circuitos dinamicamente criados na ESnet
estão relacionados com o LHC
27Km de circunferência
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]:o 10 Mbps: 300 hrs (12,5 dias)o 100 Mbps: 30 hrso 1 Gbps: 3 hrs (discos "rápidos" o bastante?)o 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ívelo Implementações TCP turbinadas (disponíveis no Linux):
Cubic, HTCP, Bic, Vegas etc
• Buffers do TCP precisam ser aumentadoso Auto-tuning de buffers (transmissor e receptor)o Disponível na maioria dos SOs
• Aplicações também precisam ser "espertas":o Ex.: GridFTP
Por que ser dinâmico?
• Configuração manual de circuito muito custosao 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 demandao 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 agendamentoo Por operadores, usuários e/ou aplicaçõeso Necessário definir políticas para tal
• Solução dinâmica se torna escalávelo Permite uma grande quantidade de circuitos sendo
automaticamente configuradoso 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:o Aspectos multidomínio, diferentes tecnologias de rede,
controle de admissão, agendamento etc• A serem destacados:
o Negociação multidomínioo Equipamentos s/ suporte a circuito virtualo 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 dadoso Plano de controle: Protocolos e SW que definem o
encaminhamento dos pacoteso 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:o Plano de controle rodando fora dos equipamentos que
fazem o encaminhamento dos dadoso 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ínioo Dependente da tecnologia de redeo Papel do DC (Domain Controller)
• Controle interdomínio cuida da negociação do circuito entre domínios vizinhoso Deve ser independente da tecnologia de redeo Sinaliza as ações de controle para o intradomínioo Papel do IDC (Inter-Domain Controller)
Detalhes de uma arquitetura DCN
[Tanaka 2009]
Softwares adotados
• Principais SWs para controle interdomínio:o OSCARS (Esnet, Internet2, RNP etc)o AutoBAHN (GEANT)o UCLP (CANARIE)
• Principal SW para controle intradomínioo DRAGON
• SWs para front-end de gerenciamento:o ION (Internet2)o MEICAN (RNP)o 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:o Transferências de dados para computação em grade
HepGrid (UERJ), Sprace (UNESP)o Transmissão de vídeo 4K (CineGRID, CPqD)o Espetáculos de dança interativao 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ó
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”
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
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
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 QinQDragon (testes)
OSCARS (conf. interd., testes)
Monitoramento
Lay-out do laboratório
• POD: conjunto de 2 switches e um servidoro Switches são Extreme ou Ciscoo Servidor é Dell com SO base VMware ESXi
• Cada POD representa um domínio:o Servidor abriga VMs do plano de controle e VMs de
clienteso 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!
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)