Your SlideShare is downloading. ×
Onix: Uma plataforma de desenvolvimento              para controle distribuído              Welington Manoel da Silva, wel...
2.1.2    Infraestrutura de conectividade                         2.3     NIBEsta infraestrutura envolve a rede em si e sua...
identificadas nas operações realizadas poderão ser                   algoritmos de consistência para estados que requeiram...
de tráfego mantendo-a isolada de possíveis rupturas no         A Onix implementa um banco de dados transacionalplano de en...
expostas a estados inconsistentes; caso isso ocorra, as                  Um DVS provê uma abstração lógica de switch em cu...
dúvida vem para facilitar a vida dos desenvolvedores deaplicações de gerência de rede ao abstrair detalhes deinfraestrutur...
Upcoming SlideShare
Loading in...5
×

Onix: Uma plataforma de desenvolvimento para controle distribuído

207

Published on

A necessidade de uma plataforma de
desenvolvimento que abstraísse os detalhes de
infraestrutura física da rede e permitisse a criação de
planos de controle mais flexíveis motivou o surgimento da
Onix, uma plataforma de controle que disponibiliza as
funções mais básicas de controle de redes e permite aos
desenvolvedores manipular o estado da rede e seus
elementos de acordo com as especificidades de cada
aplicação. Quanto às questões de escalabilidade,
confiabilidade, consistência e distribuição, uma gama de
possibilidades é oferecida, de modo que seja possível a
aplicação da plataforma em vários contextos, o que pode
ser verificado nas aplicações em desenvolvimento que
mostram sua efetividade.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
207
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Onix: Uma plataforma de desenvolvimento para controle distribuído"

  1. 1. Onix: Uma plataforma de desenvolvimento para controle distribuído Welington Manoel da Silva, welingtonms@hotmail.com, UFSCar – Campus Sorocaba.Resumo - A necessidade de uma plataforma de ou mais servidores e monitora um conjunto de switchesdesenvolvimento que abstraísse os detalhes de gerenciando a distribuição de estado – coletando,infraestrutura física da rede e permitisse a criação de distribuindo e coordenando os estados entre os diversosplanos de controle mais flexíveis motivou o surgimento da servidores – e provê uma interface sobre a qualOnix, uma plataforma de controle que disponibiliza as desenvolvedores podem construir uma diversidade defunções mais básicas de controle de redes e permite aos aplicações de gerenciamento de rede.desenvolvedores manipular o estado da rede e seus O modelo tradicional de controle engessa a criação de novaselementos de acordo com as especificidades de cada funções de controle de rede exigindo que se crie umaplicação. Quanto às questões de escalabilidade, protocolo próprio, que se tenha desenvoltura com o aspectoconfiabilidade, consistência e distribuição, uma gama de baixo-nível envolvido no problema que se pretende resolver,possibilidades é oferecida, de modo que seja possível a além da dificuldade de implantação da solução no switch. Aaplicação da plataforma em vários contextos, o que pode proposta da RDS é fazer com que qualquer nova função sejaser verificado nas aplicações em desenvolvimento que implementada sobre a API de uma plataforma de controle demostram sua efetividade. modo que as dificuldades associadas sejam responsabilidades da plataforma. Isso é possível por que asPalavras-chaves: sistemas distribuídos, plataforma de primitivas de distribuição de estado são implementadas nacontrole distribuído, gerenciamento distribuído. própria plataforma de controle, ao invés de estarem em tarefas de controle separadas, e utilizam técnicas extraídas1 INTRODUÇÃO da literatura bem conhecidas e de propósito geral ao invésO conceito e a aplicação de redes de computadores e de soluções mais específicas.sistemas distribuídos têm sido bastante discutidos nos A plataforma de controle é o grande facilitador doúltimos anos com o advento da cloud computing, que surgiu paradigma RDS e para que esta seja efetiva, desafios comocom o intuito de tornar-se a próxima etapa no generalidade, escalabilidade, confiabilidade, simplicidade edesenvolvimento, na evolução da internet (1). Com isso desempenho de plano de controle devem ser enfrentados.torna-se imprescindível a existência de um paradigma geral Nas seções que se seguem iremos tratar um pouco maisde controle de redes sob a qual a provisão de serviços seja sobre a arquitetura da plataforma Onix (Seção 2), questõesmais focada na lógica de negócio ao invés de preocupar-se que tangem requisitos de escalabilidade e confiabilidadecom detalhes de gerenciamento. (Seção 3), os mecanismos de distribuição utilizados (SeçãoPara que se alcance esse estado de desenvolvimento de 4), algumas informações sobre a implementação dasoftwares para ambientes distribuídos, necessita-se de uma plataforma (Seção 5) e, finalmente, aplicações em contextosplataforma genérica capaz de prover mecanismos de reais (Seção 6).controle em nível de rede que abstraia a distribuição deestado dos elementos que a compõe, funções básicas como 2 ARQUITETURAdescoberta de novos elementos, mecanismos de recuperação Para discussão da arquitetura da Onix dois aspectos sãode falhas, etc. e que forneça uma interface, através da qual relevantes: O contexto que a engloba enquanto plataformadesenvolvedores possam construir aplicações para o de controle e a API disponibilizada.gerenciamento de rede sem se preocupar com a visão debaixo nível de controle de rede e que se adeque às condições 2.1 Componentesespecíficas de cada domínio. Essa necessidade se agrava selevarmos em consideração requisitos de controle inerentes à 2.1.1 Infraestrutura físicacloud computing tais como maior escalabilidade, segurança, A infraestrutura física inclui além de switches e roteadores,migração de máquinas virtuais, etc. quaisquer outros elementos de rede que permitam, atravésComo resposta a essa necessidade, tanto academia quanto de uma interface, ter seu estado controlado (através deindústria (especificamente a parcela que opera grandes leitura e escrita) habilitando a Onix a manipular seuredes) têm se aplicado na definição de um padrão no qual o comportamento. Não é necessária a adição de nenhumplano de controle é desacoplado do plano de software para que este controle seja implementado.encaminhamento e é construído como um sistemadistribuído. Neste modelo, denominado Rede Definida porSoftware (RDS) (2), a plataforma de controle roda sobre um 1
  2. 2. 2.1.2 Infraestrutura de conectividade 2.3 NIBEsta infraestrutura envolve a rede em si e sua conexão com a A NIB mantém o conjunto de entidades de rede, cada qualOnix, que estabelece um canal de controle. Esse canal de com um conjunto de pares chave-valor e identificada por umcontrole pode ser tanto in-band quanto out-of-band. No identificador global de 128-bits.canal de controle in-band todo o tráfego de controle A Onix suporta tipagem forte através de entidades quecompartilha o mesmo canal de tráfego de dados na rede. No representam os elementos da rede ou sua subpartes.out-of-band uma rede separada é utilizada exclusivamente Entidades tipadas contém um conjunto de atributos (os parespara este fim. chave-valor) e métodos que executam operações sobre taisA infraestrutura de conectividade deve suportar atributos.comunicação bidirecional entre as instâncias da Onix e os A Figura 1 representa o conjunto de entidades tipadasswitches. A criação e a manutenção da estrutura de default da Onix. Além desses tipos básicos, permite-se queencaminhamento podem ser feitas utilizando-se protocolos as aplicações estendam o modelo de dados da Onix atravéspadrão de roteamento, como o OSPF (Open Shortest Path da criação de subclasses.First). Como as entidades são referenciadas na NIB por seu identificador único e global, é possível executar uma2.1.3 Onix consulta direta por uma entidade específica; adicionalmente,É um sistema distribuído que roda sobre um cluster de um uma aplicação pode registrar-se para receber notificaçõesou mais servidores físicos, sendo que cada um destes podem mediante alguma mudança de estado, adição ou remoção derodar uma ou mais instâncias da Onix. entidades. Com isso, a lógica de controle de uma aplicaçãoEnquanto plataforma de controle a Onix é a responsável por pode atuar a seu modo e criar seus próprios mecanismos dehabilitar a lógica de controle das aplicações a operar sobre o manipulação do estado da rede, modificando os atributos dasestado dos elementos de rede (através da leitura e escrita) e entidades envolvidas.por disseminar o estado da rede para outras instâncias dentro A NIB não provê nenhum tipo de mecanismo de bloqueiode um cluster. distribuído, mas oferece um mecanismo de requisição de2.1.4 Lógica de controle acesso exclusivo e liberação da instância local da NIB. IssoA lógica de controle de rede é codificada sobre a API da garante que nenhuma thread rodando na mesma instância iráOnix e determina o comportamento da rede através do uso executar uma atualização no mesmo instante, mas nãodas primitivas necessárias para manipulação de estado dos garante que a mesma permanecerá intocada por outraselementos que compõe a rede. instâncias Onix ou mesmo algum elemento de rede. Para cobrir essa deficiência, é necessário utilizar mecanismos2.2 A API implementados externamente, conforme abordado no tópico Mecanismos de distribuição da NIB.O intuito da Onix é “definir uma API útil e genérica paracontrole da rede que permita o desenvolvimento deaplicações escaláveis” (2). Através da visibilidade da redefísica, ela permite às aplicações ler e escrever estado dequaisquer elementos, provendo métodos para manter aconsistência tanto entre estes quanto na própria aplicação decontrole rodando entre múltiplas instâncias.Em uma visão mais minimalista, a API Onix consiste de ummodelo de dados que representa a infraestrutura da rede,sendo que a lógica utilizada em uma aplicação para controledistribuído pode ler o estado associado a um determinadoobjeto (que representa um elemento de rede), alterar o Figura 1 - As classes padrão que representam as entidades de redeestado da rede através da manipulação de objetos e registrar- fornecidas pela API. Linhas unidirecionais representam herança e linhasse para notificação em caso de mudança no estado dos bidirecionais representam relações de mapeamento quantitativo. Nós, portas e links constituem a topologia de rede.objetos.A cópia do estado atual da rede é mantida em uma estrutura Todas as operações realizadas na NIB são assíncronas. Issode dados chamada Network Information Base (NIB) que quer dizer que uma operação de atualização realizada sobrearmazena um grafo de todas as entidades na topologia; é uma entidade da rede, eventualmente, será enviada a umatravés da replicação e distribuição da NIB entre as elemento de rede e/ou outra instância Onix sem garantias demúltiplas instâncias que a Onix consegue prover ordenação ou latência. Por um lado isso torna operações deescalabilidade. A detecção e a resolução de conflito durante múltiplas atualizações mais eficientes, por outro lado, naa replicação e a distribuição são dependentes da lógica de maioria das vezes é necessário saber se a operação disparadacada aplicação em específico. Ainda a garantia de foi completada com sucesso. Para isso, a API fornece umaconsistência pode ser customizada a fim de se adequar a primitiva de sincronização na qual, uma vez que adiferentes cenários. requisição de atualização for concluída, a lógica de controle recebe uma chamada de retorno e pode inspecionar o conteúdo da NIB a fim de verificar se o estado corrente era o esperado para o procedimento realizado. Quaisquer falhas 2
  3. 3. identificadas nas operações realizadas poderão ser algoritmos de consistência para estados que requeiram umanotificadas à aplicação pela NIB. consistência forte, e provendo detecção e resolução deA Tabela 1 lista as categorias de operações disponíveis na conflitos para casos de exceção.NIB bem como a finalidade de cada uma dela. Por padrão, a Onix fornece dois tipos de armazenamento de dados que uma aplicação pode utilizar para lidar comCategoria Finalidade diferentes preferências de durabilidade e consistência. ParaConsulta Buscar por entidades. estados que exijam alta durabilidade e consistência, oferece-Criar, excluir Criar e excluir entidades. se um banco de dados transacional replicado e para estados voláteis – mais tolerantes a inconsistências – uma DHTAcesso a Inspecionar e modificar entidades. (Distributed Hash Table) armazenada em memória. Naatributos DHT, itens de dados são associados a uma chave aleatóriaNotificações Receber atualizações sobre mudanças. de um espaço de identificadores de n-bits (usualmente, 128Sincronização Esperar que atualizações sejam ou 160-bits dependendo da função hash utilizada). Da aplicadas no conteúdo dos elementos mesma forma, os nós (arquivo, processo, elemento de rede, da rede e dos controladores. etc.) são associados a números aleatórios do mesmo espaçoConfiguração Configurar como os estados são de identificadores. O intuito é estabelecer um esquema importados e exportados da NIB. eficiente e determinístico que mapeia unicamente a chave dePull Solicitar que entidades sejam um dado ao identificador de um nó. Quando se busca por importadas sob demanda. um dado, o endereço de rede do nó responsável por este dado é retornado e a busca é concluída com a requisição doTabela 1 - Operações disponíveis para a NIB listadas de acordo sua dado ao nó responsável (3).categoria e finalidade. 3.2 Confiabilidade3 ESCALABILIDADE E CONFIABILIDADE Para assegurar confiabilidade, as aplicações baseadas naSendo a NIB a base para o estado do sistema e seus eventos, Onix têm de gerenciar quatro tipos de falhas na rede: Falhasua utilização determina as propriedade de escalabilidade e em elementos de encaminhamento, falha de link, falha emconfiabilidade. Ora, se o número de elementos presentes na instâncias Onix e falha de conectividade entre elementos derede aumenta, uma NIB não distribuída pode exaurir a rede e instâncias Onix e entre as próprias instâncias Onix.memória do sistema; se o número de eventos na rede(gerados pela NIB) aumenta o trabalho requerido para 3.2.1 Falhas de elemento de rede e de linkgerenciá-los, pode saturar a CPU de uma única instância da Se um elemento de rede falha, a função da aplicação deOnix. controle é desviar o tráfego de dados dos elementos problemáticos. O tempo mínimo de reação mediante a tais3.1 Escalabilidade falhas é determinado pelo tempo de disseminação da falhaA Onix suporta três estratégias que podem ser usadas para pela rede juntamente com o tempo de recálculo das tabelasmelhorar a escalabilidade dos sistemas de controle: de encaminhamento. Com o intuito de tornar esse tempoparticionamento, agregação e consistência e durabilidade. mínimo o suficiente para a recuperação, pode ser válido a utilização de caminhos backups em associação com algum3.1.1 Particionamento outro mecanismo de recuperação.A lógica de controle pode configurar a Onix de modo queuma instância do controlador mantenha apenas um 3.2.2 Falha de uma instância Onixsubconjunto da NIB na memória e tal conjunto estará Para gerenciar esse tipo de falha a lógica de controle daatualizado. Com isso, uma instância da Onix pode ter aplicação possui duas opções: alguma das instâncias aindaconexões com um subconjunto de elementos e, em funcionamento pode detectar o nó defeituoso e assumirsubsequentemente, terá um menor número de eventos suas responsabilidades, ou ainda pode se utilizar ogerados para processar. gerenciamento redundante de elementos de rede. Caso a segunda opção seja a escolhida, a lógica de controle deve3.1.2 Agregação lidar com a perda de atualização em casos de atuaçãoEm uma configuração multi-Onix, uma instância pode expor concorrente. Para isso, a Onix fornece um meio para que asum subconjunto de elementos em sua NIB como um aplicações possam determinar se alterações conflitanteselemento agregado para outras instâncias. Por exemplo, na feitas por outras instâncias podem ou não ser sobrescritas.rede do campus de uma Universidade, cada prédio pode sergerenciado por um controlador Onix que expõe todos os 3.2.3 Falha de conectividadeelementos de deste prédio como um único nó agregado para O mecanismo de distribuição de estados da Onix é separadouma instância global da Onix que controla a engenharia de da topologia subjacente. Portanto, em casos de recuperaçãotráfico do campus inteiro. de falha, a conectividade é requerida tanto entre os elementos de rede e as instancias Onix, quanto entre as3.1.3 Consistência e durabilidade instâncias Onix.A lógica de controle determina os requisitos de consistência Não são incomuns redes que possuem uma rede física oupara a rede que ela gerencia. Isto é feito através da virtual dedicada para gerenciamento. Nestes ambientes, aimplementação de um mecanismo de bloqueio distribuído e Onix pode utilizar essa rede de gerenciamento para controle 3
  4. 4. de tráfego mantendo-a isolada de possíveis rupturas no A Onix implementa um banco de dados transacionalplano de encaminhamento. Essa rede de controle funciona replicado para disseminação de todas as atualizações queda mesma forma que qualquer outra rede, sendo assim, suas requerem durabilidade e gerenciamento simplificado defalhas são tratadas através dos protocolos tradicionais (por consistência. Um banco de dados replicado vem comexemplo, OSPF ou Spanning Tree (4)). severas limitações de desempenho (6) e, portanto, serve Mesmo que não haja uma rede de controle separada, a apenas como um mecanismo de propagação confiável paratopologia da rede física é conhecida pela Onix. Logo, a estados de rede com baixas taxas de mudança. Selógica de controle pode popular os elementos de rede com necessário, uma API de consultas baseada em SQL, triggers,um estado de encaminhamento estático para estabelecer a e modelagem de dados é disponibilizada.conectividade entre a Onix e os switches. Para assegurar a Pra integrar o banco de dados replicado com a NIB, Onixconectividade na presença de falhas, o roteamento padrão inclui módulos de importação/exportação. Estespode ser combinado com o multi-pathing (também componentes leem e armazenam entidades e seus atributosimplementado pela Onix) (5): o roteamento de pacotes por de/para o banco de dados. As modificações realizadas namúltiplos caminhos pode garantir conectividade confiável NIB podem ser agrupadas e enviadas ao banco de dados empara os elementos da rede gerenciada, bem como para as uma única transação. Quando um módulo de importaçãoinstâncias Onix. recebe a invocação de uma trigger do banco de dados que anuncia mudança de conteúdo, ele aplica estas alterações à4 MECANISMOS DE DISTRIBUIÇÃO DA NIB NIB.O mecanismo de distribuição de estado da Onix foi guiado Para estados de rede que requerem altas taxas de atualizaçãopor duas observações feitas sobre aplicações de e disponibilidade, a Onix provê uma DHT eventualmentegerenciamento de rede. Primeiro, aplicações possuem consistente, armazenada em memória, relaxando asdiferentes requisitos de escalabilidade, frequência de garantias de durabilidade e consistência. Atualizações naatualização em espaço compartilhado e durabilidade; DHT disparados por múltiplas instâncias Onix podem levarsegundo, aplicações possuem requisitos distintos de a estados inconsistentes. Neste caso, fica por conta daconsistência do estado de rede que gerenciam. aplicação ou resolver o conflito ou evitar essas condiçõesPara atender a aplicações com esses diferentes requisitos, usando mecanismos de coordenação distribuídos.Onix permite a escolha entre velocidade de atualização e 4.2 Gerenciamento de estado de elemento de rededurabilidade fornecendo dois mecanismos separados para A plataforma não determina um protocolo particular paradistribuição de atualização de estados de rede entre gerenciamento de estado de encaminhamento de uminstâncias: um projetado para altas taxas de atualização com elemento de rede. Através da interface provida pela NIB,disponibilidade assegurada, e outra projetada para dar qualquer protocolo suportado pelos elementos na rede podesuporte à durabilidade e consistência. O desenvolvedor de ser usado desde que as entidades na NIB estejamuma aplicação pode então estabelecer um trade-off entre sincronizadas com o estado atual da rede. Um exemplo deperformance e escalabilidade e determinar explicitamente o protocolo suportados é o OpenFlow (7); Para permitir amecanismo que será adotado para os estados da NIB. integração, os eventos e operações do OpenFlow sãoA Onix também suporta diferentes sistemas de transformados em estados, que por sua vez são armazenadosarmazenamento, desde que as aplicações escrevam seus e manipulados como entidades da NIB.próprios módulos de importação e exportação quetransferem dados do sistema de armazenamento para a NIB 4.3 Consistência e coordenaçãoe da NIB para o sistema de armazenamento, A NIB é o ponto de integração central para dados vindos derespectivamente. múltiplas fontes (outras instâncias Onix e outros elementosSobre as preferências por diferentes requisitos de de rede), ou seja, os mecanismos de distribuição de estadoconsistência, a Onix espera que as aplicações utilizem as não interagem diretamente com cada um deles; ao invésfacilidades de coordenação providas pela plataforma para disso, eles importam e exportam estado de/para a NIB. Paraimplementar bloqueio distribuído ou protocolo de consenso, suportar aplicações com diferentes requisitos deconforme necessário. Também espera-se que seja codificada escalabilidade e confiabilidade é necessário que cadaa lógica para tratamento de inconsistência devido a aplicação declare que dados devem seratualizações caso não se tenha optado por uma consistência importados/exportados de determinada fonte através damais rígida; a plataforma disponibiliza um framework para configuração dos respectivos módulos.auxiliar as aplicações nestas implementações. Como a integração de fontes de dados é feita sem exigir4.1 Distribuição de estado entre instâncias Onix consistência, estados inconsistentes são armazenados ou devido à inconsistência de estado dentro da uma fonteDiferentes mecanismos são disponibilizados para manter o específica de dado (DHT) ou devido à inconsistência entreestado consistente entre as instâncias Onix e entre as diferentes fontes. Por isso, a Onix espera que as aplicaçõesinstâncias Onix e os elementos de rede, basicamente porque registrem sua lógica de resolução de inconsistência naswitches possuem baixa capacidade de processamento e plataforma. As aplicações podem fazê-lo de duas formas: a)limitações de memória, sendo necessário que o protocolo Na Onix, as entidades são classes C++ que a aplicação podeadotado seja leve e garanta consistência no estado de estender e, portanto, espera-se que a herança seja utilizadaencaminhamento. para englobar a lógica de detecção de inconsistência referencial nas entidades para que as aplicações não sejam 4
  5. 5. expostas a estados inconsistentes; caso isso ocorra, as Um DVS provê uma abstração lógica de switch em cujasmudanças inconsistentes permanecem pendentes dentro da portas declaram-se políticas. Estas portas estão ligadas àsNIB até que possam ser aplicadas ou as aplicações máquinas virtuais através da integração com o hypervisors.declarem-nas como inválidas; b) Os plug-ins que as Enquanto as máquinas vão e vem em torno da rede, o DVSaplicações passam para os componentes de assegura que as políticas sigam as VMs e, portanto, não têmimportação/exportação implementam a lógica de resolução de ser reconfiguradas manualmente; com essa finalidade, ode conflitos, permitindo ao módulo de importação discernir DVS integra-se à plataforma de virtualização.como resolver situações onde tanto a NIB local quanto a Quando operando como parte de uma aplicação DVS, afonte do dado possuem mudanças para o mesmo estado. Onix não é envolvida na estrutura de fluxo do plano de encaminhamento, mas é invocada quando as VMs são5 IMPLEMENTAÇÃO criadas, excluídas ou migradas. Hypervisors são organizadosA Onix consiste de aproximadamente 150.000 linhas de em pools4 que consistem de um número razoavelmentecódigo escritas em C++ e integra certo número de pequeno de hypervisors e VMs tipicamente não migrambibliotecas de terceiros. Basicamente ela contém lógica para entre pools. Baseando-se nessa organização, a lógica decomunicação com elementos de rede, agregar informações controle pode facilmente particionar-se de acordo com essesna NIB e prover um framework no qual os programadores pools. Uma única instância Onix lida com todos ospossam escrever aplicações de gerenciamento. hypervisors de um único pool. Todo o estado deUma única instância da Onix pode rodar sobre muitos configuração de switch é persistido no banco de dadosprocessos, cada qual codificado usando diferentes transacional, ao passo que a localização das VMs não elinguagens de programação, se necessário. Os processos são compartilhada entre as instâncias Onix.interconectados usando Remote Procedure Call (RPC) – a Em caso de falha em uma instância da Onix, a rede aindamesma interconexão das instâncias Onix – mas ao invés de pode operar, entretanto, VMs dinâmicas não mais serãorodar sobre TCP/IP, roda sobre conexões IPC1 local. Neste permitidas (2).modelo, suportar uma nova linguagem de programação é só 6.2 Data centers virtualizados multi-locatáriosuma questão de escrever alguns milhares de linhas de códigopara integração. Atualmente a Onix suporta as linguagens Em ambientes multi-locatários, além de ter de gerenciar aC++, Python e Java. dinâmica de hospedeiros finais, a rede têm de forçar oIndependente da linguagem de programação, todos os isolamento de endereçamento e de recursos entre locatários.módulos da Onix são escritos como componentes com baixo Redes locatárias podem ter, por exemplo, sobreposição deacoplamento, que podem ser substituído por outros sem endereços MAC ou IP e podem rodar sobre a mesmanecessidade de recompilação da plataforma, desde que a infraestrutura física.interface do componente binário permaneça a mesma. Para atender a essa necessidade, foi desenvolvida umaComponentes podem ser carregados e descarregados aplicação baseada na Onix que permite a criação de redesdinamicamente, e os desenvolvedores podem expressar as específicas com configuração independente para cada rededependências entre os componentes para assegurar que eles locatária e provê um modelo de serviço Ethernet padrão.sejam carregados e descarregados na ordem apropriada. A lógica de controle isola as redes locatárias encapsulando os pacotes nas bordas antes que eles adentrem a rede física e6 APLICAÇÕES descapsulando–os quando entram em outro hypervisors ou são entregues à internet.As sessões seguintes discorrem sobre algumas aplicações A lógica de controle estabelece túneis entre todos osconstruídas sobre a Onix. hypervisors que rodam as máquinas virtuais anexadas a uma6.1 Distributed Virtual Switch determinada rede locatária virtual e, para evitar que o gerenciamento desses túneis exceda a capacidade de umaEm ambientes corporativos virtualizados, as bordas na instância Onix, ela particiona a rede entre múltiplastopologia da rede consistem de switches baseados em instâncias distribuindo as responsabilidades entre elas. Umasoftware dentro de hypervisors2 ao invés de switches de rede única instância gerencia apenas um subconjunto defísica. Não é incomum a implantação virtual (especialmente hypervisors, mas publica a informação de seu ponto terminalem provedores de hospedagem em cloud) consistir de de túnel na DHT para que qualquer outra instância quemilhares ou dezenas de milhares de Virtual Machines (VMs, necessite estabelecer um túnel envolvendo um de seusMáquinas Virtuais) no total. Estes ambientes são altamente hypervisors possa configurar o módulo de importação dadinâmicos, de modo que VMs são adicionadas, excluídas e DHT para ler as informações relevantes para a NIB.migradas on the fly3. Para atender a necessidade de taisambientes surge o conceito de Distributed Virtual Switch 7 CONCLUSÃO(DVS). Considerando que ambientes de rede específicos exigem implantação de soluções específicas, e que estas por sua vez1 requerem protocolos específicos que demandam uma Inter-Process Communication é qualquer método de passagem de dadosentre processos rodando em espaços de endereçamento diferentes. abordagem mais baixo nível e um maior nível de2 Responsável por monitorar as máquinas virtuais conhecimento, a Onix, dentro do paradigma SND, sem3 Ou seja, as máquinas virtuais são migradas sem que seus processos em 4execução sejam interrompidos. Grosseiramente um pool é equivalente a um cluster, um agrupamento. 5
  6. 6. dúvida vem para facilitar a vida dos desenvolvedores deaplicações de gerência de rede ao abstrair detalhes deinfraestrutura física e permitir o foco na lógica de controlebaseado na API. Além disso, proporciona a liberdade dedeterminação do trade-off entre arquitetura potencialmentesimplificadas – promovendo consistência e durabilidade – eoperações mais eficientes com aumento considerável decomplexidade.Graças as possibilidade e versatilidade de aplicação emdiferentes domínios a Onix tem grandes chances decrescimento no ambiente de cloud computing, permitindogerência e customização de mais baixo nível em serviçossob demanda.8 REFERÊNCIAS1. Hurwitz, Judith, Bloor, Robin e Kaufman, Marcia.Cloud computing for dummies - HP Special Edition.Hoboken, NJ : Wiley Publishing, Inc, 2010. 978-0-470-63881-1.2. Koponen, Teemu, et al., et al. Onix: A DistribuitedControl Platform for Large-Scale Production Networks.3. Tanenbaum, Andrew. Distribuited Systems, Principlesand Paradigms. New Jersey : Prentice Hall, 2007. 0-13-239227-5.4. Kurose, James F. e Ross, Keith W. Computernetworking, a top-down approach featuring the Internet. 3ª.s.l. : Pearson, 2006. 85-88639-18-1.5. Akella, Aditya. Multi-Path Routing: A DifferentPerspective. s.l. : Carnagie Mellon University.6. Elmasri, Ramez e Navathe, Shamkant B. Fundamentalsof database systems. s.l. : Pearson, 2004. 0-321-12226-7.7. Mckeown, N., et al., et al. OpenFlow: EnablingInnovation in Campus Networks. SIGCOMM CCR 38. 2,2008.8. Hunt, P., et al., et al. ZooKeeper: Wait-free Coordinationfor Internet-Scale Systems. Usenix Annual TechnicalConference. Junho de 2010.9. Link Layer Discovery Protocol (LLDP), a new standartfor discovering and Managing converged network device.Extreme Networks Technical Brief - Extreme Networks, Inc. 6

×