Minicurso DMZ Científica RSA5 LARC - PCS EPUSP

Agenda Introdução Motivação e-ciência e Transferência de Dados Redes Corporativas vs Redes Científicas Problemas enfrentados pelos pesquisadores DMZ Científica Modelo de DMZ Científica Iniciativas de DMZ Científica Arquitetura da DMZ Científica Conectividade Interna/Externa Switches de alta capacidade DTN Monitoramento perfsonar Serviços Avançados de Rede Exemplos

Agenda Segurança Premissas do modelo de segurança Modelo de segurança Recomendações de segurança Montagem de uma DMZ Científica Arquitetura de Rede Conectividade Escolha do Hardware Configurações/Otimizações Testes Experimentos Resultados Considerações Finais

Introdução Profa. Tereza Cristina de Melo Brito Carvalho Fernando Frota Redigolo Dino Raffael Cristofoleti Magri

Introdução Motivação e-ciência e Transferência de Dados Redes Corporativas vs Redes Científicas Problemas enfrentados pelos pesquisadores

Motivação Tradicionalmente, a ciência é baseada em dois pilares: a teoria e a experimentação. Teoria à Geração de Hipóteses Experimentação à Validação da Teoria Teorias complexas têm demandado Simulações e análises computacionais Geração de dados via sensores e instrumentos especializados (e.g.: sequenciadores de genoma, aceleradores de partículas)

Motivação Pode-se dizer que a ciência moderna têm um terceiro pilar: a Tecnologia Digital. A combinação desses três pilares deu origem ao termo e-ciência (e- Science). Um efeito importante do uso destas tecnologias para o apoio à ciência é o volume de dados gerados.

Motivação Em algumas áreas da ciência os sensores e simuladores podem geral alto volume de dados Física de Partículas, Astronomia, Ciências da Terra (Earth Science) e Ciências da Vida (Life Science) Os pesquisadores realizam trabalhos científicos colaborativos e compartilham recursos computacionais e dados.

Motivação Com essa colaboração é necessário movimentar grandes volumes de dados, da ordem de gigabytes ou até mesmo terabytes por dia. As redes de comunicação tornam-se fundamentais para viabilizar e fomentar a e- ciência.

Motivação Instituição Aplicação Volume Observações UFRJ Imagens e vídeos Neurologia 200GB/ dia Não conseguem realizar a pesquisa porque eles tem problemas de conexão e banda. UFPE INPE USP Banco de Dados de Genética Vegetal Dados Meteorológico 18TB/dia 240 MB/ dia Wget 3 a 4 semanas scp - 4 a6 semanas 24 horas para transferir Possíveis caso de uso: - Instituto de Astronomia, Geofísica e Ciências Atmosférica - Instituto de Física

Motivação Tempo mínimo para transferência de 1TB (em condições ideais): 30 horas (100 Mbps) 3 horas (1 Gbps) 20 minutos (10 Gbps).

e-ciência e Transferência de Dados Porém nem sempre as coisas acontecem como no mundo ideal... Experimento de transferência de arquivos com diferentes ferramentas Servidor A" Roteador Servidor B" Linux"

e-ciência e Transferência de Dados Experimento 1: cluster de emulação de redes (Emulab/ProtoGENI) Servidores físicos dedicados sem otimização. Transferência disco-a-disco: 3 tamanhos de arquivos: 1GB, 10GB e 50GB. 3 ferramentas: scp, ftp, xrootd. Enlaces de 1Gbps, com roteamento. Testes com enlaces (iperf) indicaram 914 Mbps disponível para transferência de A para B.

e-ciência e Transferência de Dados Ferramentas com diferentes vazões. 800 700 Mesma ferramenta com diferentes vazões dependendo o tamanho do arquivo!! Vazão (Mbps) 600 500 400 300 200 100 0 SCP FTP XrootD 50G 10G 1G SCP FTP XrootD 50G 209.60 375.23 396.27 10G 210.93 436.32 493.07 1G 217.60 658.67 795.47

e-ciência e Transferência de Dados E a questão de segurança? Transferência de arquivos com e sem firewall Servidor A" Firewall Linux" Servidor B"

e-ciência e Transferência de Dados Experimento 2: cluster de emulação de redes (Emulab/ProtoGENI) Servidores físicos dedicados sem otimização. Transferência disco-a-disco: 1 tamanho de arquivo: 1GB. 1 ferramenta: xrootd Enlaces de 1Gbps, com roteamento. Testes com ou sem regras no firewall 6314 regras iptables

e-ciência e Transferência de Dados Vazão Xrootd - Arquivo 1G (Mbps) 800.00 700.00 600.00 Vazão (Mbps) 500.00 400.00 300.00 200.00 100.00 0.00 Sem Firewall Com Firewall Vazão (Mbps) 795.47 24.80

e-ciência e Transferência de Dados Caso de Uso: Universidade de Utah Sem o firewall da UoU Com o firewall da UoU A UoU tem 2 enlaces de 10 Gbps para a rede de educação de Utah que tem 10 Gbps para a Internet2 Fonte: www.es.net

e-ciência e Transferência de Por que isso acontece? Dados Como investigar esta questão? Como resolver esta questão?

Redes Corporativas vs Redes Científicas Equipamentos, configurações, arquiteturas previstas para fluxos tradicionais de Rede Corporativas: Aplicações Internet: Web, Email, VoIP, P2P, Vídeo,... Sistemas Corporativas: ERP, Finanças,... Sistemas de Controle: catracas, CCTV (Closed-Circuit TeleVision),... Dispositivos: desktops, notebooks, smartphones, tablets,... Segurança: Firewalls, IDS, Proxies,...

Redes Corporativas vs Redes Científicas Fluxos Tradicionais H"p Smtp h"p VoIP erp p2p Imap H"p Imap H"p H"p VoIP Transferência Cien9fica Fluxos Científicos

Redes Corporativas vs Redes Científicas Fluxos Tradicionais Web, email, etc. Grande número de fluxos consumindo pouco banda. Pequena taxa de perda de pacotes não afeta desempenho de forma significativa. Filtragem complexa. Fluxos Científicos Transferência de dados Pequeno número de fluxos consumindo muita banda Pequena taxa de perda de pacotes afeta desempenho de forma significativa Controle simples

Problemas enfrentados pelos pesquisadores Os principais problemas nas infraestruturas de rede atuais para e-ciência são: Controle de Congestionamento do TCP Janela de Transmissão Dimensionamento de buffer nos equipamentos de Rede. Firewall Hard Failure Soft Failure

Controle de Congestionamento do TCP Transferências entre instituições geograficamente dispersas Podem apresentar atraso considerável na transferência Entidades envolvidas Número e caracterisiticas dos equipamentos de interconexão. Long Fat Network é caracterizada pelo elevado produto da largura de banda pelo atraso (BDP - Bandwidth Delay Product) Largura de Banda (bps) * Atraso (segundos)

Controle de Congestionamento do TCP BDP (Bandwidth Delay Product) reflete a quantidade de dados que pode estar trafegando na rede entre dois pontos, sem a necessidade de confirmação do TCP. Depende de: Dimensionamento de buffers Janelas de transmissão O uso ótimo da rede implica em buffers e janelas de transmissão adequadas à situação

Exemplos de BDP para um rede de 1 Gbps RTT de 1ms (Local) BxD = 10⁹ bits/s x 10 ³ s 10⁶ bits 1Mbit BxD = 1Mbit / 8 = 125KB Controle de Congestionamento do TCP RTT de 70 ms (entre estados Brasil) BxD = 10⁹ bits/s x 7x10 ² s 7 x 10⁷ bits 70 Mbits BxD = 70 Mbits / 8 = 8.75 MB RTT de 200 ms (Internacional) BxD = 10⁹ bits/s x 2x10 ¹ s 2 x 10⁸ bits 200 Mbits BxD = 200 / 8 = 25 MB

Controle de Congestionamento do TCP Os sistemas operacionais modernos contam com mecanismos de auto-tuning do TCP: Evitando ajustes manuais do tamanho dos buffers Porém são configurados para o caso médio. Outro ponto é controle de congestionamento do TCP: Uma perda de pacotes pode ser um sinal de congestionamento na rede. Diminuindo o tamanho da janela...e a vazão da rede.

Controle de Congestionamento do TCP Janelas para transmissões com alta latência são muito maiores que para transmissões de baixa latência Fluxos de longa distância mais impactados Maior demora de recuperação de uma perda Algoritmos de controle de congestionamento do TCP para redes com alto BDP CUBIC (Cubic Binary Increase Congestion Control) HTCP (Hypertext Caching Protocol)

Controle de Congestionamento do TCP Caso da Esnet: Uma pequena taxa de perda de pacotes pode ter um grande impacto no desempenho. Todas os nós conectados por uma 10G NIC. Problema numa interface de roteador de 10G. Perda de 0,0046% em uma direção (perda de 1 pacote para cada 22 mil pacotes transmitidos). Inexistência de congestionamento. MTU igual a 9000 bytes. Para diferentes mecanismos de controle de congestionamento (Reno e HTCP) Quanto maior a distância, maior impacto no desempenho.

Controle de Congestionamento do TCP

Controle de Congestionamento do TCP Desta maneira é possível ver que Para um transferência eficiente de dados científicos a longa distância com TCP deve ser provido um caminho de rede otimizado fim-a-fim, sem perdas de pacotes

Picos de Tráfego Tamanho dos buffers também é importante nos switches e roteadores ao longo do caminho de uma transferência de dados Nas situações de janelas de transmissão grandes, os equipamentos de rede ao longo do caminho podem receber grandes volumes de tráfego em rajadas. Para evitar que os equipamentos de rede descartem pacotes e provoquem diminuição no fluxo TCP: Deve-se ter maior capacidade de armazenamento nos equipamentos de rede.

Picos de Tráfego Desta forma, os equipamentos de rede devem: Ter capacidade de armazenamento para suportar picos do volume de tráfego. Como regra básica de dimensionamento de buffers, tem-se: B = overlinertt x C, onde: RTT = Round-Trip Time do fluxo. C = taxa de transmissão do enlace Armazenar os dados do fluxo em buffers. 1. Quando há picos de utilização na rede 2. Diferença de velocidade entre duas intefaces do mesmo equipamento de rede (interface de 10Gbps 1Gbps Elasticidade x latência

Firewalls Outro ponto é a existencia de Firewall, que são gargalos para os fluxos científicos São projetados para trabalhar com um grande número de conexões de curta duração O que implica em algumas questões arquiteturais

Firewalls Características dos Firewalls: Grande número de buffers de tamanho pequeno para atender às conexões simultâneas. Múltiplos núcleos ou unidades de processamento com capacidade de processamento menor que a capacidade nominal do firewall Tabelas de estado normalmente são dimensionadas com timeouts apropriados para conexões de curta duração Em um fluxo científico de alto volume Firewall não tem capacidade suficiente de processamento e armazenamento

Firewalls Em geral, Firewalls executam um grande número de análises a cada pacote. O uso do firewall como intermediários de fluxos científicos deve ser evitado.

Falhas Hard-failure Outros problemas de rede... Hard-failure: falha de algum elemento ou componente da rede de maneira que ele não pode prover o serviço de conectividade. Exemplos: Falha de uma interface ou um equipamento de rede. Perda de sinal em uma fibra óptica rompida. Esses erros podem ser facilmente detectados pela perda de conectividade em um dado trecho da rede.

Falhas Soft-failure Outros problemas de rede... Soft-failure: algum elemento ou componente apresenta um comportamento que afeta o desempenho de aplicações e/ou da rede, porém ainda provê um serviço básico de conectividade e não chega a disparar alarmes no sistema de gerenciamento da rede Exemplos: Perda de pacotes em interfaces defeituosas ou fibras com problemas. Rotas congestionadas. Configuração errônea.

Soft-failure Falhas Soft-failure

Falhas Soft-failure As soft-failures: não impactam de forma significativa as aplicações com baixo volume de tráfego. podem permanecer sem serem detectadas por meses. são difíceis de serem isoladas. Portanto as soft-failures representam grandes desafios para e-ciência.

DMZ Científica Profa. Tereza Cristina de Melo Brito Carvalho Fernando Frota Redigolo Dino Raffael Cristofoleti Magri

DMZ Científica Modelo de DMZ Científica Iniciativas de DMZ Científica Programa Science DMZ RNP - Projeto SD² FAPESP DMZ USP e DMZ OSU Arquitetura da DMZ Científica Conectividade Interna/Externa Switches de alta capacidade DTN (Data Transfer Node) Monitoramento perfsonar Serviços Avançados de Rede Circuitos Virtuais. SDN (Software Defined Networking) Exemplos Advanced Light Source (ALS) San Diego State University (SDSU) Florida International University (FIU)

Modelo de DMZ Científica A segregação das aplicações científicas permite: Simplificar as tarefas de otimização da rede para fluxos científicos. Analisar problemas de desempenho. Implementar mecanismos de segurança apropriados para não comprometer o desempenho das aplicações.

Modelo de DMZ Científica O modelo de DMZ Científica foi proposto pela ESnet para mitigar os problemas encontrados nos ambientes de pesquisa com aplicações de e-ciência. Consiste em um segmento especializado da rede de um laboratório ou campus, localizado próximo ao perímetro da rede, especialmente projetado para aplicações científicas de alto desempenho.

Modelo de DMZ Científica Componentes de uma DMZ Científica: Sistemas dedicados e otimizados para transferências de dados em alta velocidade a longa distância, Mecanismos de monitoramento e testes de rede interinstitucionais; Mecanismos e políticas de segurança próprios para aplicações científicas de alto desempenho, diferenciadas das existentes na rede de produção.

Iniciativas de DMZ Científica EUA (Esnet, Internet2, Ohio) Brasil (RNP, FAPESP-OSU) Pilares para Inovação em Pesquisa e Educação

Iniciativas de DMZ Científica Programa Science DMZ RNP Estudar e disseminar melhores práticas de infraestrutura de redes de campus voltadas às aplicações científicas. Adequar modelos externos à realidade nacional (ex.: modelo ESnet) O programa engloba um grupo de desenvolvimento e diferentes grupos de casos de uso.

Iniciativas de DMZ Científica RNP - Grupo de Desenvolvimento Projeto SD² (Software Defined Science DMZ) Coordenadores: Tereza Cristina M. B. Carvalho (carvalho@larc.usp.br) Fernando Frota Redigolo (fernando@larc.usp.br) Equipe: Dino Raffael Cristofoleti Magri (dino@larc.usp.br) Luis Felipe de Almeida da Silva (lsilva@larc.usp.br) Rafael Augusto Brandão (rbrandao@larc.usp.br) Marco Antonio Torrez Rojas (matrojas@larc.usp.br) Patrocinador: RNP (Rede Nacional de Pesquisa)

Iniciativas de DMZ Científica RNP - Grupo de Desenvolvimento Desenvolver um protótipo do modelo de DMZ Científica para ser implementado em instituições brasileiras. Especificação e implantação dos equipamentos da DMZ Científica em 6 instituições: Kits de baixo custo com capacidade de de 1G e 10G Podem ser adquiridos no Brasil e são de fácil implantação. Disseminar o conceito e promover implantações da DMZ Científica.

Iniciativas de DMZ Científica RNP - Grupo Casos de Uso As instituições selecionadas Kit de 10G: USP, INPE e RNP* Kit de 1G: UFRJ, ON*, IFPE*, UFPE Auxílio na implantação da DMZ Científica. Medições entre as instituições utilizando o perfsonar. Testes de transferências entre os DTNs.

Iniciativas de DMZ Científica Chamada FAPESP-OSU USP participa com o projeto de interligação de sua DMZ Científica com a DMZ da Ohio State University. Objetivo Estabelecimento de pesquisas colaborativas entre as duas instituições que envolvam a transferência de grandes volumes de dados nas áreas de telemedicina, veterinária, artes e entretenimento, clima, astronomia e física de alta energia, entre outras.

Arquitetura da DMZ Científica Principais Requisitos de uma DMZ Científica: Uma arquitetura de rede projetada de acordo com as necessidades das aplicações científicas, de maneira a garantir o seu desempenho; Um ou mais servidores dedicados e otimizados para transferência de dados em alta velocidade a longa distância (DTN) Um ou mais servidores para monitoramento e testes de redes interinstitucionais, de maneira a permitir o rápido isolamento de pontos da rede com problemas de baixo desempenho (perfsonar). Mecanismos e políticas de segurança próprios para aplicações científicas de alto desempenho.

Arquitetura da DMZ Científica A arquitetura DMZ NÃO é FIXA, devendo ser adequada à rede da instituição e à necessidade de suas aplicações. A ESnet propõe algumas arquiteturas para que seja possível compreender os elementos da DMZ Científica.

Arquitetura da DMZ Científica DTN Rede Acadêmica perfsonar Banda perfsonar Atraso Switch Roteador de borda DMZ Científica Firewall Laboratório de Pesquisa Rede Produção Campus Arquitetura Básica

Arquitetura da DMZ Científica Arquitetura para Centro de Supercomputação

Arquitetura da DMZ Científica Arquitetura de rede deve ser construída para lidar com altas taxas de fluxos de dados sem perda de pacotes para as aplicações. Otimização do acesso externo visando perfil colaborativo Deve ser configurada para permitir a identificação e solução de problemas, facilitando o isolamento de falhas.

Arquitetura Conectividade Externa Conectividade externa friction-free Quantidade reduzida de equipamentos no caminho para a WAN que possam ser pontos de congestionamento e/ou perda de pacotes. Localização privilegiada na rede da instituição (roteador de borda e fora do firewall). Uso opcional de enlace externo dedicado, separando-a do enlace externo da rede acadêmica. Uso opcional de circuitos de camada 2 entre as instituições.

Arquitetura Conectividade Interna Conectividade Interna Tem alta largura de banda e baixa latência. Redução de problemas de desempenho decorrentes de perdas de pacotes. Dependendo da necessidade das aplicações e da estrutura da rede interna, pode ser necessário tratar o tráfego científico de forma diferenciada Exemplo: Fibras internas dedicadas, vlans

Arquitetura - Equipamentos de Rede de Alta Capacidade Equipamentos de rede no caminho do fluxo científico devem atender às necessidades de comutação e de armazenamento em buffers para o tráfego com alto BDP (Bandwidth Delay Product). Raramente a quantidade de buffers é divulgada. Lista com alguns equipamentos mantida pela comunidade cientifica pode ser vista em http://people.ucsc.edu/~warner/buffer.html

Arquitetura da DMZ Científica Data Transfer Node (DTN) Nós especializados para transferência de grandes quantidades de dados através de milhares de quilômetros o mais rápido possível Leitura dos dados (I/O) Envio dos dados Rede Escrita dos dados (I/O) Fluxo básico do DTN

Arquitetura da DMZ Científica Data Transfer Node (DTN) Tipicamente servidores Linux construídos para maximizar o desempenho da transferência de dados, mesmo em detrimento de redundâncias Hardware Software Testes realizados (Tabela 1): Berkeley, CA até Argonne, IL. RTT de 53 milissegundos. Taxa de transmissão da rede igual a 10 Gbps.

Arquitetura da DMZ Científica Tabela 1 - Data Transfer Node (DTN) Ferramenta Discos Taxa de Transferência Scp 1 140 Mbps (17.5 MB/s) HPN-scp 1 760 Mbps (95 MB/s) HPN-scp RAID-0 1.2 Gbps (150 MB/s) GridFTP com 1 fluxo 1 760 Mbps (95 MB/s) GridFTP com 1 fluxo RAID-0 1.4 Gbps (175 MB/s) GridFTP com 4 fluxos RAID-0 5.4 Gbps (675 MB/s) GridFTP com 8 fluxos RAID-0 6.6 Gbps (825 MB/s) RAID-0 com 4 discos Para desempenho acima de 1 Gbps deve-se utilizar RAID-0

Monitoramento perfsonar Oferece serviços de medição e testes fim-a-fim, bem como uma infraestrutura de protocolos para a criação de novas ferramentas de medição em um rede específica. Arquitetura voltada para medição e testes multidomínios. O perfsonar foi adotado pela Internet2, RNP, ESnet, GÉANT, LHC, entre outros. Auxílio na detecção de softfailures

Monitoramento perfsonar Os servidores devem estar localizados em pontos estratégicos e/ou críticos da rede

Monitoramento perfsonar Permite identificar os trechos com problemas na transferência de dados. As ferramentas básicas do perfsonar estão disponíveis em um kit denominado ps-toolkit BWCTL Avalia a banda efetiva disponível com TCP e UDP. OWAMP Realiza testes de atraso. perfsonar-buoy Permite agendar e armazenar os testes de banda e latência

Ex. PerfSonar Teste Regular de Banda

Ex. PerfSonar Teste Regular de Latência

Serviços Avançados de Rede Objetivos Melhoria de desempenho dos fluxos científicos sobre as redes acadêmicas regionais e nacionais: Manipulação no encaminhamento de pacotes Principais serviços Circuitos Virtuais SDN (Software Defined Networking)

Serviços Avançados de Rede Circuitos Virtuais Camada 3 (Layer 3 ou L3): é o serviço tradicional de conectividade entre instituições acadêmicas sobre uma rede IPv4/IPv6, de melhor esforço, com roteamento dos pacotes ao longo da rede. Camada 2 (Layer 2 ou L2): permite criar uma VLAN de camada 2 fim-a-fim entre dois ou mais pontos da rede acadêmica, com requisitos de banda garantidos. Úteis para aplicações especiais que necessitam de menor latência e maior largura de banda do que aqueles oferecidas pela Internet tradicional.

Serviços Avançados de Rede Circuitos Virtuais L2 Configuração estática: Processo manual, demorado e sujeito a erros Envolve coordenação e conferências via skype/email Circuitos dinâmicos: Infraestrutura baseada em OSCARS (On-Demand Secure Circuits and Advance Reservation System): Permite criar circuitos virtuais sob demanda automaticamente entre duas instituições separadas por múltiplos domínios administrativos. No Brasil é oferecida por meio do Serviço Cipó (SE-Cipó) da RNP ainda em fase experimental

Serviços Avançados de Rede Circuitos Virtuais L2 O uso de circuitos virtuais L2 também permite o uso de protocolos diferenciados para a transferência de dados, como por exemplo o RDMA RDMA (Remote Direct Memory Access) Utilizam funcionalidades implementadas na própria interface de rede para transferência com alto desempenho e baixo consumo de CPU Ex.: RoCE RDMA over Converged Ethernet

Serviços Avançados de Rede SDN (Software-Defined Networking) É uma arquitetura de rede emergente onde o plano de controle do equipamento de rede é fisicamente separado do plano de dados, com o plano de controle gerenciando múltiplos equipamentos. Essa separação permite que aplicações e serviços de rede possam interagir com o plano de controle via APIs. Os planos de controle são interligados por meio de um protocolo específico para este fim, sendo o OpenFlow o mais conhecido.

Serviços Avançados de Rede SDN (Software-Defined Networking) O uso do paradigma de SDN e de OpenFlow ainda é incipiente dentro do contexto de uma DMZ Científica, porém existem algumas abordagens, como: Implementação de funcionalidades de segurança com SDN. Interligação da DMZ Científica com os serviços de circuito virtual baseados na plataforma OSCARS. Redirecionamento automático de tráfegos científicos para os circuitos virtuais e/ou enlaces dedicados de uma infraestrutura para e-ciência. Criação automática de circuitos virtuais com SDN interligando as entidades parceiras da colaboração científica.

Exemplos de DMZ Científica Advanced Light Source (ALS) É uma divisão do Lawrence Berkeley National Laboratory (LBNL) especializada no uso de feixes de raio-x para pesquisas cientificas. O fluxo de trabalho consiste em: captura de dados por sensores especializados (detectores); envio destes dados para análise no cluster computacional do NERSC (National Energy Research Scientific Computing Center); e devolução dos dados analisados ao ALS para refinamento da análise em estações de trabalho especializadas locais.

Exemplos de DMZ Científica

Exemplos de DMZ Científica Advanced Light Source (ALS) O tráfego da captura encontra-se isolado da rede de produção, alimentando diretamente o DTN do ALS. Evita-se, assim, o congestionamento na rede.

Exemplos de DMZ Científica San Diego State University (SDSU) Necessidade de transferência de dados em larga escala para diferentes pesquisas (simulações numéricas de terremos, modelagem da costa oceânica, bioinformática, entre outros) Arquitetura DMZ Científica distribuída, composta por uma DMZ principal e DMZs periféricas localizadas em prédios distintos, interligadas por meio de enlaces dedicados.

Exemplos de DMZ Científica San Diego State University (SDSU) A arquitetura adotada cria uma rede paralela na SDSU para aplicações científicas do laboratório até o backbone da rede regional. Permite um ajuste fino em cada DTN de acordo com as particularidades de cada área de pesquisa.

Exemplos de DMZ Científica Florida International University (FIU) Uma arquitetura distribuída e baseada em SDN/ OpenFlow, indo do perímetro da rede até os laboratórios de pesquisa. Baseada no conceito do rack FlowSurge que consiste em um kit contendo um nó perfsonar, switches e controlador OpenFlow, a ser colocado no laboratório de pesquisa. A partir da estrutura do FlowSurge são criadas regras OpenFlow, de maneira que o tráfego científico seja encapsulado dentro da rede de produção da FIU até a DMZ Científica.

Segurança Profa. Tereza Cristina de Melo Brito Carvalho Fernando Frota Redigolo Dino Raffael Cristofoleti Magri

Segurança Premissas do modelo de segurança Modelo de segurança Recomendações de segurança

Premissas do Modelo de Segurança Duas premissas fundamentais: O isolamento do tráfego científico do tráfego de propósito geral A simplicidade dos fluxos científicos do ponto de vista de segurança A primeira premissa decorre do próprio modelo da DMZ Científica

Premissas do Modelo de Segurança A segunda premissa decorre das seguintes caracteristicas: Pequena quantidade de máquinas que devem ser protegidas Os nós de uma DMZ são dedicados para uma única atividade Pequeno conjunto de protocolos a ser controlado (transferência de arquivos e de monitoração/testes) A transferência de dados pode ser restrita a um conjunto pequeno de entidades externa

Premissas do Modelo de Segurança A segregação do tráfego bem como a simplicidade dos fluxos científicos, implicam nos seguintes aspectos do ponto de vista de segurança: As políticas de segurança para a rede corporativa e para a DMZ Científica são aplicadas em pontos distintos da rede, o que deve ser feito de forma apropriada, sem que as políticas da rede corporativa afetem o tráfego científico e vice-versa; A utilização de sistemas dedicados e um conjunto limitado de aplicações reduzem as vulnerabilidades, os elementos de ataques e os esforços em manter a segurança

Premissas do Modelo de Segurança Existe uma pequena quantidade de fluxos referentes a um número limitado de tipos de aplicação (e.g., transferência de arquivos), não sendo necessário mecanismos de segurança mais complexos do que o estritamente necessário para tratar tais fluxos; Alguns mecanismos de segurança podem ser tratados diretamente nos nós da DMZ Científica (e.g., HIDS Hostbased Intrusion Detection System) e/ou a nível de aplicação (e.g., autenticação e controle de acesso nas aplicações de transferência).

Modelo de Segurança O tráfego da DMZ Científica não deve atravessar firewalls, no entanto não significa que o tráfego para a DMZ Científica não seja filtrado A filtragem é realizada por Listas de Controle de Acesso (ACLs) implementadas nos roteadores e/ou switches de alto desempenho da DMZ. ACLs são processadas em hardware provendo o desempenho adequado para as aplicações científicas.

Modelo de Segurança As ACLs podem prover um nível de segurança adequado à DMZ, uma vez que a DMZ não precisa da sofisticação da proteção e da análise em profundidade de um firewall Devem restringir o tráfego às aplicações (portas) e aos nós remotos autorizados a interagir com os DTNs e perfsonars internos Trata-se de uma abordagem diferenciada e mais adequada às aplicações científicas

Modelo de Segurança Este modelo de não utilização de um firewall tradicional tem implicações na política de segurança da instituição. É de vital importância que a equipe de segurança da instituição esteja de acordo com o modelo de segurança da DMZ Científica, o qual é calcado em paradigmas diferentes daqueles pressupostos para ambientes de computação tradicionais.

Recomendações de Segurança As políticas e mecanismos de segurança devem ser projetados com base nos níveis de risco associados ao ambiente de alto desempenho da DMZ Científica E desenvolvidos com componentes que escalem até as taxas de dados requeridas, sem causar problemas de desempenho. A seguir são relacionadas as principais recomendações de políticas de segurança a serem aplicadas no contexto de DMZ Científica:

Recomendações de Segurança Os recursos da DMZ Científica devem ser são projetados para interagir com sistemas externos e são isolados dos sistemas internos. O tráfego da rede de produção deve estar isolado do tráfego da DMZ Científica. O tráfego para a DMZ Científica deve possuir políticas de segurança diferenciadas do tráfego de produção da instituição, e implementadas de forma separada. As políticas de segurança e sua execução devem ser específicas para fluxo de trabalho da DMZ Científica O tráfego da DMZ Científica deve ser habilitado somente de/para as instituições parceiras, por meio da liberação do endereço IP e porta TCP utilizada na comunicação

Recomendações de Segurança A política de segurança e sua respectiva implementação é fortemente dependente da localização da DMZ Científica. Deve-se utilizar ACLs nos switches ou roteadores para a filtragem de tráfego científico em detrimento à utilização de um firewall, pois o alto volume deste tráfego é tipicamente maior que a capacidade do hardware de firewalls convencionais. Sugere-se a utilização de ACLs concomitantemente com um IDS de alto desempenho Gerenciamento de segurança do ambiente de DMZ Científica deve ser tratado de forma conjunta com o gerenciamento de segurança da instituição

Montagem DMZ Científica Profa. Tereza Cristina de Melo Brito Carvalho Fernando Frota Redigolo Dino Raffael Cristofoleti Magri

Montagem de uma DMZ Científica Arquitetura de Rede Conectividade Conectividade Externa Conectividade Interna Escolha do Hardware Switch DTN (Data Transfer Node) Placa Mãe Arquitetura do Disco Interfaces de Rede perfsonar Configurações/Otimizações DTN perfsonar

Arquitetura de Rede Depende das aplicações científicas a serem utilizadas e da própria rede da instituição. Para facilitar a implantação da DMZ Científica nas instituições parceiras do projeto foi definida uma arquitetura genérica que pudesse ser usada como base para implantação. Arquitetura foi baseada no modelo da ESnet e adaptada à realidade encontrada nas instituições parceiras.

Arquitetura Básica Arquitetura de Rede

Conectividade Externa DMZ Científica com compartilhamento de enlace com a Internet. DMZ Científica com compartilhamento de enlace com a Internet e circuitos virtuais. DMZ Científica com enlace independente à Internet.

Conectividade Externa As conexões externas para a rede acadêmica devem ser compartilhadas entre o tráfego da rede de produção e o tráfego da DMZ. É necessário realizar alterações no roteador de borda da instituição, bem como alocar uma porta livre para interligação com o switch da DMZ.

Conectividade Externa É necessário que o roteador tenha alta capacidade de buffers. A conexão externa é considerada adequada quando o tráfego de produção não é suficientemente alto a ponto de sobrecarregar o roteador de borda, interferindo no tráfego científico.

Conectividade Externa DMZ Científica com compartilhamento de enlace com a Internet

Conectividade Externa DMZ Científica com compartilhamento de enlace com a Internet. DMZ Científica com compartilhamento de enlace com a Internet e circuitos virtuais. DMZ Científica com enlace independente à Internet

Conectividade Externa Caso haja problema no compartilhamento do enlace externo, a arquitetura pode ser complementada com o uso de circuitos virtuais (SE- CIPO). Evitando problemas de interferência entre tráfegos científico e de produção.

Conectividade Externa Arquitetura Básica com Circuitos L2

Conectividade Externa Conectividade com Circuitos Virtuais: Pode demandar configurações mais complexas, uma vez que para se utilizar circuitos virtuais dinâmicos é necessário agregar ao ambiente da instituição à infraestrutura do serviço de aprovisionamento de circuitos (OSCARS) Se o número de circuitos virtuais for pequeno e sofra poucas alterações, uma alternativa é o uso de circuitos estáticos, aprovisionados manualmente.

Conectividade Externa DMZ Científica com compartilhamento de enlace com a Internet DMZ Científica com compartilhamento de enlace com a Internet e circuitos virtuais DMZ Científica com enlace independente à internet

Conectividade Externa O tráfego científico NÃO passa pelo roteador da instituição. Elimina-se, assim, um ponto de atrito. Custos adicionais (portas e enlaces adicionais) O uso dessa opção é necessário quando o roteador de borda não apresenta o desempenho necessário para o tráfego agregado

Conectividade Externa

Conectividade Interna Para conectar os laboratórios de pesquisa à DMZ Científica, a maneira mais simples é utilizar a rede de produção do Campus Não há necessidade de isolar o tráfego entre os laboratórios de pesquisa da instituição e a DMZ Científica Não é necessário utilizar usar buffers de alta capacidade, uma vez que as conexões internas possuem baixa latência

Conectividade Interna Porém pode ser interessante isolar esse tráfego nos seguintes casos: Políticas de segurança da instituição Sobrecarga na infraestrutura de produção E no caso de uma DMZ Científica Distribuída o isolamento do tráfego vira uma necessidade

Conectividade Interna

Escolha do Hardware Switch O dimensionamento das portas do switch deve ser planejado em função das ligações internas, externas, bem como a quantidade de servidores ligados Outro ponto é que o nós do DTN e de monitoramento de banda do perfsonar devem ter a mesma velocidade da interface de saída da DMZ Científica

Escolha do Hardware Switch Verificar se o switch tem capacidade de comutação sem bloqueios (non-blocking switch) Todas as portas operando em full-duplex Switch com 24 portas de 1G e 4 portas de 10G, o switch deve ter capacidade de comutação de ao menos 128 GB Um bom valor de referência para o tamanho do buffer é um valor próximo do valor esperado do BDP

Escolha do Hardware Switch A Esnet sugere switches com 60MB de buffer para situações com RTT de 50 ms e taxa de transferência de 10G (~62,5MB) Para maior escalabilidade, recomenda-se que o switch tenha funcionalidades avançadas para encapsulamento de tráfego em camada 2, tais como Q-in-Q ou MPLS, suporte um grande número de identificadores de VLAN, além de OpenFlow em modo híbrido

Escolha do Hardware DTN (Data Transfer Node) A configuração deve ser focada em hardware especializado, nas otimizações de rede e de sistema e nas aplicações especializadas. No que tange ao hardware especializado, deve-se dar atenção especial à placa mãe, à arquitetura dos discos e às interfaces de rede.

Escolha do Hardware DTN Processador e Placa mãe Deve ter o máximo número de núcleos e o mínimo número de processadores Deve ter mínimo de 32 GB de memória Slots apropriados para as placas de rede e controladora RAID (offboard)

Escolha do Hardware DTN Arquitetura de Disco Deve conter uma controladora RAID de ao menos 1G de cache e, preferencialmente, suporte a cache em discos SSD. Recomenda-se que os discos estejam em RAID-0 Discos coorporativos com taxa de transferência maior que 170 MB/s O dimensionamento da capacidade dos discos em si depende do conjunto de dados que será disponibilizado pelas aplicações científicas no DTN

Escolha do Hardware DTN Interfaces de Rede No caso de interfaces de 10Gbps ou superior, recomenda-se que a placa de rede tenha suporte a TOE (TCP Offload Engine), de maneira a otimizar seu desempenho Suporte a mecanismos de RDMA (Remote Direct Memory Access) como RoCE

Escolha do Hardware perfsonar Características dos equipamentos são determinadas pela função que a máquina irá executar Memória de 4GB e disco rígido de 1TB Em relação a interface de rede é recomendado utilizar interfaces offboard Para a máquina de atraso pode-se utilizar uma interface simples de 1G Para a máquina de banda deve-se utilizar uma interface na mesma velocidade do DTN

Hardware do Projeto RNP Escolha dos equipamentos para o projeto RNP Switch perfsonar DTN Controladora RAID

Hardware do Projeto RNP Switch Kit 1G: Brocade CES 2024C Kit 10G: Brocade CES 2024C-4X

Hardware do Projeto RNP Switch Descrição 1G 10G 24 portas 1G UTP (4 combo) L2 ACLs Mecanismos QoS 4000 VLANs (e Q-in-Q) OpenFlow 1.0 em modo híbrido por porta Porta 10G (opcional) 2 XFP 4 SFP+ Buffer 64 MB 128 MB Comutação 48 Gbps 128 Gbps Consumo 120W 256W Uplink Rede Campus 1 GBIC LX 1 SFP+ LR

Hardware do Projeto RNP Switch Switch Roteador Fibra SMF (LX ou LR) Switch Servidores 1G: UTP 10G: Coaxial

Hardware do Projeto RNP perfsonar 2 x HP Proliant DL320e Gen8 Quad-Core Intel Xeon E3-1240v2 Memória 4GB, 1x1TB 7.2K SATA Consumo: 350W NICs offboard Intel Kit 1G: Intel EXPI930CT (atraso) e Intel EXPI930CT (banda) Kit 10G: Intel EXPI930CT (atraso) e Intel 10G offboard X520-DA2 (banda)

Hardware do Projeto RNP DTN Intel E5-2630, 2.30 GHz 64 GB de memória 10 x 1TB Enterprise, 7200RPM SATA Controladora RAID Intel RS2BL080 com suporte a cache SSD Mellanox 10G MCX311A-XCAT

Configurações e Otimizações DTN perfsonar

Configurações e Otimizações DTN Distribuição CentOS do Linux - http://bit.ly/1kfngov Após a instalação base do sistema, das ferramentas e dos driver das placas de rede é necessário otimizar alguns componentes para obter um melhor desempenho nas transferências dos dados

Configurações e Otimizações DTN BIOS Habilitar o turbo boost para aumentar dinamicamente a velocidade de clock do processador Desabilitar mecanismos de hyper-threading para evitar que o processamento seja realizado por um processador virtual Desabilitar node interleaving para evitar que um processador utilize memória local de outro processador

Configurações e Otimizações DTN Interface de rede Aumentar o tamanho da fila de transmissão da interface de rede para velocidades superiores a 10Gbps (Esnet recomenda uma fila de 10.000 pacotes para 10GbE) Sempre que possível utilizar Jumbo Packets, ou seja MTU de 9.000 bytes de maneira a se otimizar o tráfego na rede

Configurações e Otimizações DTN Pilha TCP Não está configurada para situação de transferência de dados em alta velocidade com alta latência. Ajuste da pilha pode ser feita aumentando o tamanho do buffer para que redes de altas velocidades que conectam os sistemas de servidores possam lidar com uma maior quantidade de pacotes. Os principais parâmetros do TCP que afetam o desempenho encontram-se o tamanho mínimo e máximo das janelas de recebimento e transmissão do TCP, timestamps, ACKs seletivos, backlog e modo de baixa latência

Configurações e Otimizações DTN Algoritmos de congestionamento TCP Recomendado o uso do algoritmo de HTCP ou Cubic para o controle de congestionamento do TCP Controladora RAID Deve-se verificar as recomendações do fabricante em relação à otimização da controladora RAID, uma vez que diferentes controladores têm diferentes funcionalidades e portanto, diferentes opções de configuração.

Configurações e Otimizações DTN I/O Scheduler Utilize o algoritmo Deadline Scheduler para controlar o acesso ao disco por meio de agendamento de requisições de entrada e saída (I/O) via kernel do GNU/Linux Sistema de Arquivos A Esnet sugere o uso do sistema de arquivos EXT4 para um DTN, com otimizações no cache de leitura para aumentar a quantidade de dados e metadados lidos do disco Testes em laboratório indicam melhor desempenho para o sistema de arquivo XFS

Configurações e Otimizações Configurações / Otimizações DTN

Configurações e Otimizações Ferramentas para transferência de dados TCP scp scp_hpn - http://www.psc.edu/index.php/hpn-ssh wget ftp gridftp - http://toolkit.globus.org/toolkit/downloads/ UDP udr - https://github.com/labadvcomp/udr Aspera - http://asperasoft.com tixel - http://www.tixeltec.com/tixstream_en.html

Configurações e Otimizações perfsonar Instalar o perfsonar Toolkit - http://bit.ly/1mi5alp Após a instalação deve-se configurar informações administrativas, comunidades, servidores de NTP, os serviços que serão executados, além dos agendamentos dos testes.

Configurações e Otimizações perfsonar Informações administrativas Nome da organização, a localização e o contato administrativo Comunidades São agrupamentos de servidores associados a um determinado projeto. É importante adicionar os nós de monitoramento a uma ou mais comunidades, de maneira que os seus servidores possam encontra-los e adiciona-los ao seus testes (ScienceDMZ/RNP e ScienceDMZ)

Configurações e Otimizações perfsonar Configuração dos servidores NTP É importante selecionar os servidores de NTP geograficamente próximos e/ou de menor latência Serviços a serem executados Deve-se indicar quais serviços devem ser adicionados nos servidores de latência e banda, sendo que cada um desses serviços devem estar, preferencialmente, separadas.

Configurações e Otimizações perfsonar MTU Os nós dos perfsonar devem ter os mesmo MTU dos DTNs, de maneira a testar o desempenho fim-a-fim nas mesmas condições da transferência de dados. Scripts de Configuração Foram desenvolvidos alguns scripts de configuração para o projeto e podem ser acessados em: http://bit.ly/rlwqyq

Configurações e Otimizações perfsonar Testes periódicos É importante que se configure testes periódicos entre as máquinas de monitoramento das DMZs Científicas

Testes Profa. Tereza Cristina de Melo Brito Carvalho Fernando Frota Redigolo Dino Raffael Cristofoleti Magri

Experimento iperf iperf3 scp ftp gridftp 1 fluxo AWS - EUA ~ 140 ms ~ 142 ms Processador Intel E5-2670 8 GB CentOS 6.5 DTN-USP dtn.sciencedmz.usp.br Processador Intel E5-2630 64 GB RAID-0 (7 discos de 1 TB) CentOS 6.5 ~ 0.47 ms SIM-LARC-USP sim.larc.usp.br Processador Xeon 5500 32 GB 1 TB Red Hat 6

SIM-LARC-USP para DTN USP 800.00 779.30 718.80 739.83 700.00 600.00 512.08 500.00 400.00 374.30 376.96 300.00 200.00 100.00 0.00

Testes 800.00 779.30 700.00 600.00 500.00 400.00 376.96 512.08 iperf scp ftp 300.00 200.00 100.00 110.76 36.80 133.60 50.42 53.87 61.09 0.00 Lab - DTN Amazon - Lab Amazon - DTN

Considerações Finais Profa. Tereza Cristina de Melo Brito Carvalho Fernando Frota Redigolo Dino Raffael Cristofoleti Magri

Considerações Finais E-Science requer: Pesquisa Colaborativa Transferência de Volume de dados crescente. Requisitos: Banda larga de transmissão. Baixo atraso.

Considerações Finais Sistemas atuais com baixa vazão: Ferramentas inadequadas. Sistemas de segurança de proposito geral. Protocolos de transporte com suporte a controle de congestionamento para aplicações não cientificas. Servidor de armazenamento com baixa taxa de transferência. Sistemas de DMZ Científica Sistemas de segurança customizados para aplicações cientificas. Protocolo de transporte adequado. Arquitetura com componentes de alto desempenho.

Considerações Finais Sintonia com os requisitos de operação da área de TI da instituição e com as necessidades dos pesquisadores da instituição Em relação à pesquisa, é importante verificar, por exemplo, quais necessidades da pesquisa não são atendidas pelas redes atuais, com quais instituições os pesquisadores precisam trocar informações e quais são os aspectos de segurança de seus dados.

Considerações Finais Desafios Futuros DMZ Científicas com suporte a SDN/OpenFlow Controlar o compartilhamento de recursos da DMZ entre aplicações de maneira a se minimizar a interferência entre elas Solucionar alguns problemas de integração (e.g., para se integrar um serviço de circuitos dinâmicos como o SE- CIPÓ da RNP até a interface do DTN ou para se integrar equipamentos especializados na rede da instituição à DMZ).