1 / 34

DISTRIBUITED SDN CONTROLLER

DISTRIBUITED SDN CONTROLLER. MO809L – Tópicos em Computação Distribuída. Estudante: Alex Rodriguez. Professor: Leandro Aparecido Villas. Computação distribuída ou  sistema distribuído.

elysia
Download Presentation

DISTRIBUITED SDN CONTROLLER

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. DISTRIBUITED SDN CONTROLLER MO809L – Tópicos em Computação Distribuída Estudante: Alex Rodriguez Professor: Leandro Aparecido Villas

  2. Computação distribuída ou sistema distribuído • É uma referência à computação paralela e descentralizada, realizada por dois ou mais computadores conectados através de uma rede, cujo objetivo é concluir uma tarefa em comum. • Definimos um sistema distribuído como sendo aquele no qual os componentes de hardware ou software, localizados em computadores interligados em rede, se comunicam e coordenam suas ações apenas enviando mensagens entre si. Os computadores conectados por médio de uma rede podem estar separados por qualquer distância. Eles podem estar em continentes separados, no mesmo prédio ou na mesma sala. • Nossa definição de sistemas distribuídos tem as seguintes consequências importantes: • Concorrência: em uma rede de computadores, a execução concorrente de programas é a norma. Posso fazer meu trabalho em meu computador, enquanto você faz o seu em sua máquina, compartilhando recursos como páginas web ou arquivos, quando necessário.

  3. Computação distribuídaou sistema distribuído.... • Inexistência de relógios global: quando os programas precisam cooperar, eles coordenam suas ações trocando mensagens. A coordenação frequentemente depende de uma noção compartilhada do tempo em que as ações dos programas ocorrem. Entretanto, verifica-se que existem limites para a precisão com a qual os computadores podem sincronizar seus relógios em uma rede – não existe uma noção global única do tempo correto. Essa é uma consequência direta do fato de que a única comunicação se dá por meio do envio de mensagens em uma rede. • Falhas independentes: todos os sistemas de computador podem falhar e é responsabilidade dos projetistas de sistema pensar nas consequências das possíveis falhas. Nos sistemas distribuídos, as falhas são diferentes. • Falhas na rede resultam no isolamento dos computadores que estão conectados a ela, mas isso não significa que eles param de funcionar. Os programas neles existentes tal vez não consigam detectar se a rede falho ou se tornou demasiadamente lenta.

  4. Computação distribuídaou sistema distribuído.... • A falha de um computador ou o término inesperado de um programa em algum lugar no sistema (um colapso no sistema) não é imediatamente percebida pelos outros componentes com os quais ele se comunica A motivação para construir e usar sistemas distribuídos é proveniente do desejo de compartilhar recursos. O termo “recurso” é bastante abstrato, mas caracteriza bem o conjunto de coisas que podem ser compartilhadas de maneira útil em um sistema de computadores interligados em rede. Ele abrange desde componentes de hardware, como discos e impressoras, até entidades definidas pelo software, como arquivos, bancos de dados e objetos de dados de todos os tipos. Isso inclui o fluxo de quadros de vídeo proveniente de uma câmara de vídeo digital ou a conexão que uma chamada de telefone móvel representa.

  5. Computação distribuídaou sistema distribuído.... Interoperabilidade caracteriza até que ponto duas implementações de sistemas ou componentes de fornecedores diferentes devem coexistir e trabalhar em conjunto, especificados por um padrão comum; Portabilidade caracteriza até que ponto uma aplicação desenvolvida para um sistema distribuído A pode ser executada, sem medicação, em um sistema B; Extensibilidade define a capacidade de se adicionar novos componentes ou substituir componentes existentes sem afetar os que continuam no mesmo lugar. Escalabilidade com Relação ao Tamanho • Se uma quantidade maior de usuários ou recursos devem ser considerados deve-se tomar cuidado com serviços, dados e algoritmos centralizados: • Eles se tornam gargalos, pontos únicos de falhas e saturam a rede onde residem.

  6. Computação distribuída ou sistema distribuído.... Abertura • Um sistema aberto é aquele que oferece serviços de acordo com padrões que descrevem a sintaxe e semântica destes serviços; • Por exemplo, em redes de computadores existem regras que definem o formato, conteúdo e sindicado das mensagens; • Em SDs, serviços são especificados através de interfaces descritas em uma IDL (Interface Definition Language). Isso permite: 1. Um processo arbitrário que necessite de uma interface se comunique com outro processo que fornece esta interface; 2. Que sejam construídas implementações diferentes destas interfaces que funcionem do mesmo modo. • Transparência da Distribuição • de acesso; • de localização; • de migração; • de relocação: movimentação de lugar enquanto os recursos estão sendo acessados; • de replicação; • de concorrência; • de falhas.

  7. Computação distribuída ou sistema distribuído.... Exemplos: • Internet: é um conjunto de redes de computadores de muitos tipos diferentes, interligados. Permite aos usuários acessarem serviços e executarem aplicativos por meio de um conjunto heterogêneo de computadores e redes. • intranets: é uma parte da internet administrada separadamente, cujo limite pode ser configurado para impor planos de segurança locais. Desvantagens de sistemas distribuídos: Software – sistemas operacionais, linguagens de programação e aplicações. Comunicação – tratamento e recuperação de mensagens. Melhoria da rede pode acarretar em custos altos. Segurança – Compartilhamento de dados implica em esquemas especiais para proteção de dados sigilosos.

  8. Computação distribuída ou sistema distribuído.... Middleware: o term se aplica a uma camada da heterogeneidade das redes, do hardware, de sistemas operacionais e linguagens de programação subjacente. Além de resolver os problemas de heterogeneidade, o middleware fornece um modelo computacional uniforme para ser usados pelos programadores de serviços e de aplicativos distribuídos. Os modelos possíveis incluem a invocação remota de objetos, a notificação remota de eventos, o acesso remoto a banco de dados e o processamento de transação distribuído, por exemplo Java RMI ou CORBA. Heterogeneidade e migração de código: o term migração de código, ou ainda, código móvel é usado para se referir ao código que pode ser enviado de um computador para outro e ser executado no destino – os applets Java são um exemplo. Um código destinado a execução em um computador não é necessariamente a um conjunto de instruções e a um sistema operacional (Windows – Mac OS), a estratégia de máquina virtual Java (JVM) oferece uma maneira de tornar um código executável em qualquer tipo de processador (hardware) e sistema operacional. Nessa estratégia, o compilador de uma linguagem em particular gera código para uma maquina virtual, em vez de código para um processador e sistema operacional específicos.

  9. Algoritmos distribuidos • Algoritmos distribuídos possuem as seguintes diferenças com relação aos centralizados: • Nenhuma nó possui informação completa do estado do sistema; • Cada nó toma decisões baseado somente em informações locais; • A falha de um nó não inviabiliza a execução do algoritmo; • Não se pressupõe a existência de um relógio global. Algoritmos Distribuídos são usados na implementação de serviços distribuídos - executados por instâncias (processos, objetos) distribuídos Serviços Distribuídos para: • sincronização de ações (controle de concorrência) • definir ordenação global de eventos • multicast confiável • atingir o consenso entre vários processos • captura de estado global (p.ex. detecção de deadlock) Exemplos: • escalonamento de processos em sistemas operacionais distribuídos (ex. Sistema operacional Mach) • Implementação de serviços tolerantes a falha usando replicação • middleware para comunicação de Grupo (ex. Jgroups); anutenção da consistência de dados replicados (ex: BD distribuídos); Infra-estruturas para computação em nuvem

  10. Algoritmos distribuidos Elementos Complicadores

  11. Algoritmos distribuidos Paralelismo e Indeterminismo: • Processos executam em paralelo (simultaneamente) • Processos executam em nós independentes • Nós podem ter velocidades de processamento diferentes • Escalonamento de execuções em cada nó está fora de controle (pelo S.O.) Impossibilidade de Sincronização perfeita entre processos. • As dificuldades são: • ausência de sincronismo dos relógios dos nós da rede • a duração da transmissão de cada mensagem é imprevisível • falhas de processadores ou na comunicação podem impossibilitar a sincronização • Exemplo: É impossível garantir que em Δt segundos todos processos troquem mensagens

  12. A importância do Modelo • Algoritmos que funcionam para modelos menos restritivos são mais gerais, mas tendem a ser menos eficientes, • pois introduzem redundâncias (de mensagens, de dados, de tempo) para compensar ausência de algumas premissas no modelo (p.ex. transmissão confiável de mensagens) Algoritmos para um modelo mais restritivo tendem a ser mais simples, aproveitam melhor algumas características intrínsecas do sistema • mas não funcionam se as premissas do modelo não forem satisfeitas O grau de complexidade de um algoritmo distribuído depende : • do grau de incerteza –> determinado pelo modelo (p.ex. possibilidade de falha, topologia dinâmica, etc.) e • da independência do comportamento (execução/falhas) dos processos • da ausência de sincronismo

  13. Complexidade de um Algoritmo Distribuído • Geralmente é expressa em função do número de processos N e do número de eventos inesperados f. • Tempo: • Numero de rodadas necessárias (para modelos síncronos) • Espaço: • Tamanho de dados de controle adicionais acrescidos às mensagens • Tamanho do buffer a ser mantido em cada nó • Comunicação: • Número de mensagens por rodada • Número de mensagens por evento inesperado

  14. Principais aspectos dos modelos Modelo de Interação & Sincronismo: – toda comunicação e sincronização é através de mensagens – topologia, grau de confiabilidade das mensagens e sincronismo – definição do possível atraso na comunicação & grau de sincronismo (capacidade de sincronizar ações) Modelo de Falhas: – os tipos de falha esperados (omissão ou aleatória, capacidade de detecção) – número máximo de falhas simultâneas ou probabilidade de falhas - > permite definir a estratégia para mascarar as falhas (redundância) Modelo de Segurança: – definição das possíveis formas de ataques - > permite uma análise dos riscos e o projeto de mecanismos & protocolos para impedir (ou dificultar) os ataques

  15. Modelos de Interação e Sincronização O Modelo Síncrono: • cada “passo de execução” em um processo demora entre [min, max] unidades de tempo • a transmissão de qualquer mensagem demora um limite máximo de tempo • o relógio local a cada processo tem uma defasagem limitada em relação ao relógio real A execução ocorre em rodadas de “processamento & comunicação” perfeitamente sincronizadas: • O não-recebimento de uma mensagem em determinado período também traz informação!! Obs: Em sistemas reais, é difícil determinar estes limites de tempo. Mas este modelo é adequado quando a rede é dedicada e as tarefas (processos) têm tempos de processamento fixos e bem conhecidos (p.ex. controle de processos, processador paralelo)

  16. Exemplo de Algoritmo para Modelo Síncrono Consenso: Cada nó escolhe um valor v ∈ [0, max] e difunde este valor para todos os demais nós na rede. Quando um nó tiver recebido o valor de todos os demais nós, escolhe o valor mais votado (ou no caso de empate, um valor default) como o valor de consenso d. Pseudo-código para nó i: Init => { escolhe valor v; broadcast (v:i) para todos os vizinhos localset← {(v:i)} } Nova rodada => { recebe conjunto c de mensagens dos demais; diff← c - localset; // diferença entre conjuntos se diff≠ ∅ { localset← localset∪ diff; broadcast diff para vizinhos; } senão se (já recebeu de todos nós) { d ← acha_mais_votado(localset); terminou ← true; } } Terminou => imprime o valor de consenso d; Propriedade: Assumindo-se comunicação confiável e rede com N processos, após N-1 rodadas, deverá ter recebido o valor de todos os nós ativos (não falhos).

  17. SDN y Openflow • O termo SDN (Software Defined Networking) descreve uma arquitetura que separa o Plano de Dados do Plano de Controle dos equipamentos de rede como Switches e Roteadores. Com o SDN o Plano de Controle é administrado em Software Centralizado separado do equipamento de rede e é independente de soluções e protocolos dos fabricantes (desde que soluções abertas sejam utilizadas). • O Openflow é o protocolo impulsionador do padrão SDN, apesar da arquitetura ser independente do protocolo.

  18. OPENFLOW O OpenFlow é uma proposta tecnológica que, baseada na separação dos planos de controle e de dados em comutadores de pacotes, permite que pesquisadores executem seus experimentos em redes utilizadas no dia-a-dia, sem interferir no tráfego de produção. A proposta é fundamentado em comutadores Ethernet comerciais e define um protocolo padrão para controlar o estado destes comutadores (tabela de fuxos, estatísticas e etc.). O conceito de fluxo é o bloco fundamental que habilita aos pesquisadores definir o plano de encaminhamento na rede, conforme os objetivos definidos pelas novas propostas de arquiteturas e protocolos de rede. O OpenFlow também define um novo elemento de rede, o controlador, e software de controle que executa nele, entre os quais o software NOX criado pelo grupo OpenFlowda U. Stanford

  19. OPENFLOW No OpenFlow é proposto um mecanismo que é executado em todos os comutadores ou roteadores de forma que se possa haver isolamento entre os tráfegos, o experimental e o de produção. Assim, o OpenFlow possibilita que os pesquisadores reprogramem os comutadores, sem provocar interferência na configurações da rede de produção. Outro objetivo dessa proposta é permitir que os fabricantes possam incluir as funcionalidades do OpenFlow nos seus comutadores sem necessitarem expor o projeto desses equipamentos. OpenFlow tem como objetivo ser flexível para atender aos seguintes requisitos: • possibilidade de uso em implementação de baixo custo e de alto desempenho; • capacidade de suportar uma ampla gama de pesquisas científicas; • garantia de isolamento entre o tráfego experimental e o tráfego de produção; • consistência com a necessidade dos fabricantes não exporem o projeto de suas plataformas.

  20. OPENFLOW O OpenFlow explora a tabela de fluxo que já existe nos comutadores atuais, e normalmente são utilizadas para implementar serviços como NAT, firewall e VLANs. O comutador OpenFlow é constituído de uma tabela de fluxos e um evento associado a cada entrada na tabela. Basicamente, a arquitetura do OpenFlow é composto por três partes: Tabela de Fluxos: Cada entrada na tabela de fluxos contém uma ação associada, e consiste em Campos do cabeçalho (utilizado para definir um fluxo), ações (define como os pacotes devem ser processados e para onde devem ser encaminhados) e contadores (utilizados para estatísticas ou remoção de fluxos inativos). Canal Seguro: Para que a rede não sofra ataques de elementos mal intencionados, o SecureChannel assegura confiabilidade na troca de informações entre o comutador e o controlador. A interface utilizada para acesso ao tráfego é o protocolo Secure Socket Layer (SSL). O NOX também suporta outras interfaces (passivas ou ativas), TCP e PCAP. Essas são bem úteis em ambientes virtuais, pela simplicidade de utilização, pois não necessitam de chaves criptográficas. Protocolo OpenFlow: Disponibiliza um protocolo aberto para estabelecer a comunicação entre o comutador e o controlador. Ao fornecer uma interface externa que atue sobre os fluxos de um comutador, o Protocolo OpenFlow (OFP - OpenFlowProtocol) evita a necessidade de um comutador programável.

  21. OPENFLOW Aplicações Como visto anteriormente, o OpenFlow permite o experimento de novas propostas na área de Redes de Computadores, utilizando uma infraestrutura de rede já existente. Dentre os possíveis experimentos permitidos, podem ser citados os seguintes: Novos Protocolos de Roteamento: Os algoritmos de um protocolo de roteamento podem ser implementados para executarem no controlador de uma rede OpenFlow. Assim, quando um pacote do experimento chegar a um comutador, ele é encaminhado para o controlador, que é responsável por escolher a melhor rota para o pacote seguir na rede a partir dos mecanismos do protocolo de roteamento proposto. Após isso, o controlador adiciona entradas na Tabela de Fluxos de cada comutador pertencente à rota escolhida. Os próximos pacotes desse fluxo que forem encaminhados na rede não necessitarão serem enviados para o controlador; Mobilidade: Uma rede OpenFlow pode possuir pontos de acesso sem-fio, permitindo que clientes móveis utilizem sua infraestrutura para se conectarem a Servidores ou à Internet. Assim, mecanismos de handoff podem ser executados no Controlador realizando alteração dinâmica das tabelas de fluxo dos comutadores de acordo com a movimentação do cliente, permitindo a redefinição da rota utilizada;

  22. OPENFLOW Redes Não-IP: Como visto anteriormente, um comutador OpenFlow pode ser desenvolvido para analisar campos arbitrários de um pacote, permitindo flexibilidade na definição do fluxo. Assim, podem ser testadas, por exemplo, novas formas de endereçamento e roteamento. Nos comutadores do “tipo 0”, os pacotes Não-IP podem ser definidos pelo endereço MAC de origem ou destino ou a partir de um novo Tipo de Ethernet ou IP; Redes com Processamento de Pacotes: Existem propostas de protocolos que realizam processamento de cada pacote de um fluxo como, por exemplo, os protocolos de Redes Ativas. Esse tipo de proposta pode ser implementado no OpenFlowforçando que cada pacote que um comutador receba seja enviado para o Controlador para ser processado. Outra alternativa é enviar esses pacotes para processamento por um comutador programável, como é o caso de um roteador programável baseado em NetFPGA

  23. MININET Para a criação de uma arquitetura SDN é necessário múltiplos componentes em sua infraestrutura. Inicialmente precisamos de uma máquina controladora operando algum sistema operacional de rede, como por exemplo, o NOX ou o POX. Posteriormente se fazem necessários elementos encaminhadores que tenham o plano de controle separado do plano de dados com alguma interface de programação, como por exemplo o OpenFlow. Além disso, ainda é necessário toda uma infraestrutura física que interligue esses elementos encaminhadores e o controlador por um canal seguro para a criação de uma Rede Definida por Software. O MiniNet é uma ferramenta para a simulação de Redes Definidas por Software que permite a rápida prototipação de uma grande infraestrutura virtual de rede com a utilização de apenas um computador. O Mininet também possibilita a criação de protótipos de redes virtuais escaláveis baseados em software como OpenFlowutilizando primitivas de virtualização do Sistema Operacional. Com essas primitivas, ele permite criar, interagir e customizar protótipos de Redes Definidas por Software de forma rápida. Com o MiniNet é possível realizar testes de depuração e de resoluções de problemas podendo se beneficiar de ter uma rede completa experimental em um laptop ou PC. Fornece, de maneira intuitiva, ferramentas para o desenvolvimento de aprendizagem na área de redes. Sua interface permite sua utilização em pesquisas e em aulas para o uso prático de técnicas e soluções de redes.

  24. MININET O MiniNet é melhor executado em máquina virtual (VM MiniNet) sendo executada em VMware ou VirtualBox para os sistemas operacionais Windows, Mac e Linux com ferramentas OpenFlow já instaladas. São algumas características do MiniNet: • Fornecer uma maneira simples e barata para a realização de testes em redes • para desenvolvimento de aplicações OpenFlow; • Permite que múltiplos pesquisadores possam trabalhar de forma independente na mesma topologia de rede; • Permite o teste de uma topologia grande e complexa, sem mesmo a necessidade de uma rede física; • Inclui ferramentas para depurar e executar testes em toda a rede; • Dá suporte a inúmeras topologias, e inclui um conjunto básicos de topologias; • Oferece API’s simples em Python para criação e experimentação de redes.

  25. MININET Topología • single, • linear, • tree y • custom.

  26. Problema • SDN tem um controlador centralizado (centralized controller(Openflow)); padece de scalability y reliability • o mapping entre switch e o controlador é configurado estaticamente (staticallyconfigured) • Difícil para o plano de controle se adaptar às variações de carga de tráfego (traffic), exemplo menos tráfego durante a noite

  27. 1. Desenho dum controlador distribuído, algoritmo de eleição master/sclave e armazenamento de dados distribuídos Resolver problema

  28. 1. Desenho dum controlador distribuído, algoritmo de eleição master/sclave e armazenamento de dados distribuídos Resolver problema

  29. 1. Desenho dum controlador distribuído, algoritmo de eleição master/sclave e armazenamento de dados distribuídos Resolver problema

  30. 2. Algoritmo de loadadaptation: loadmeasurement, adaptationdecisioncomputation, andmigrationaction Resolver problema

  31. BIBLIOGRAFIA • A. Tootoonchian, S. Gorbunov, Y. Ganjali, M. Casado, and R. Sherwood, “On Controller Performance in Software-Defined Networks,” in HotICE, 2012. • A. Tootoonchian and Y. Ganjali, “HyperFlow: A Distributed Control Plane for OpenFlow,” in INM/WREN, 2010. • “Open vswitch,” openvswitch.org. • N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, et al., “Openflow: enablinginnovation in campus networks,” SIGCOMM CCR, 2008. • T. Koponen et al., “Onix: A DistributedControl Platform for Large-scaleProduction Networks,” in OSDI, 2010. • N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. Mckeown, and S. Shenker, “NOX: TowardsanOperating System for Networks,” in SIGCOMM CCR, 2008. • Z. Cai, A. L. Cox, and T. S. E. Ng, “Maestro: A system for scalable OpenFlow control,” Tech. Rep. TR10-11, CS Department, Rice University, Dec. 2010. • Distributed Algorithms , Nancy A. Lynch, editor ACM Press, Hardcover, Published 1993, ISBN 0201624273 • Distributed Systems for System Architects Paulo Veríssimo, LuísRodrigues, Kluwer Academic Publishers, Hardcover, Published 2002

More Related