ESCALABILIDADE E RESILIÊNCIA NA COMUNICAÇÃO DOS MÓDULOS DA ARQUITETURA ROUTEFLOW

Transcrição

1 UNIVERSIDADE SÃO FRANCISCO Curso de Engenharia de Computação DAVI GONÇALES PETERLINI FERNANDO CAPPI LUIZ GUSTAVO MAION PAULO ROBERTO CASTELLETTO ESCALABILIDADE E RESILIÊNCIA NA COMUNICAÇÃO DOS MÓDULOS DA ARQUITETURA ROUTEFLOW Itatiba 2013

2 DAVI GONÇALES PETERLINI R.A FERNANDO CAPPI R.A LUIZ GUSTAVO MAION R.A PAULO ROBERTO CASTELLETTO R.A ESCALABILIDADE E RESILIÊNCIA NA COMUNICAÇÃO DOS MÓDULOS DA ARQUITETURA ROUTEFLOW Monografia apresentada ao Curso de Engenharia de Computação da Universidade São Francisco, como requisito parcial para obtenção do título de Bacharel em Engenharia de Computação. Orientadora: Prof.ª M.ª Débora Meyhofer Ferreira. Itatiba 2013

3 DAVI GONÇALES PETERLINI FERNANDO CAPPI LUIZ GUSTAVO MAION PAULO ROBERTO CASTELLETTO ESCALABILIDADE E RESILIÊNCIA NA COMUNICAÇÃO DOS MÓDULOS DA ARQUITETURA ROUTEFLOW Monografia aprovada pelo Curso de Engenharia de Computação da Universidade São Francisco, como requisito parcial para obtenção do título de Bacharel em Engenharia de Computação. Data de aprovação: 04 / 12 / 2013 Banca Examinadora: Prof.ª M.ª Débora Meyhofer Ferreira (Orientadora) Universidade São Francisco Prof. Esp. Glauco Kiss Leme (Examinador) Universidade São Francisco Prof. M.e Márcio Henrique Zuchini (Examinador) Universidade São Francisco

4 Aos nossos respectivos familiares, por todo apoio e confiança nesta jornada.

5 AGRADECIMENTOS Inicialmente nossos agradecimentos à Deus, pela oportunidade de formarmos esta equipe de trabalho que tanto nos orgulha e honra. Agradecemos à Prof.ª Débora Meyhofer Ferreira, não apenas pela orientação deste Trabalho de Conclusão de Curso, mas principalmente pela confiança, parcimônia e companheirismo conosco face aos percalços do trajeto. À Prof.ª Vânia Franciscon Vieira, por atender pacientemente às nossas solicitações, e pelas orientações recebidas durante a disciplina Trabalho de Conclusão de Curso. Agradecemos ainda, ao corpo docente do Curso de Engenharia de Computação da Universidade São Francisco, que com seus ensinamentos, hoje, se expressam em parte neste trabalho. Ao Prof. Christian Rodolfo Esteve Rothenberg, pela inspiração e pela ampliação dos nossos conhecimentos, nos trazendo à tona para o mundo do RouteFlow. Agradecemos à Fundação CPqD Centro de Pesquisa e Desenvolvimento em Telecomunicações, pela infraestrutura necessária à implementação deste projeto. Ao corpo de pesquisadores do CPqD Allan Vidal, Eder Leão Fernandes, Fabiano Silva Mathilde, Jorge Henrique de Barros Assumpção que colaboraram para atingirmos as metas deste trabalho. Enfim, a todos que direta ou indiretamente nos ajudaram a concluir esta etapa de nossas vidas, nosso muito obrigado!

6 A mente que se abre a uma nova ideia jamais voltará ao seu tamanho original Albert Einstein

7 RESUMO Este trabalho propõe o aprimoramento do Projeto RouteFlow, implementando escalabilidade e resiliência na comunicação entre os módulos integrantes da arquitetura. Para concretizar esta visão, apresenta-se o conceito de OpenFlow, uma API aberta para programação do plano de encaminhamento de switches, que nos últimos anos vem apurando o comportamento das redes através de aplicações. Motivada pela visibilidade das tecnologias de Redes Definidas por Software, advindas pelo protocolo OpenFlow, a Fundação CPqD desenvolveu o Projeto RouteFlow, uma arquitetura de código aberto que permite a virtualização de operações de roteamento IP em redes OpenFlow, por meio da separação efetiva do plano de controle do plano de encaminhamento dos equipamentos de rede, que procura combinar o alto desempenho de hardware de prateleira (commodities) com a flexibilidade de uma pilha de roteamento executada remotamente em computadores de uso geral. No entanto, até a completude desta monografia, o modo como o banco de dados estava implementado no RouteFlow não possibilitava a replicação da base de dados e, além disso, seu failover não estava configurado de maneira automatizada. Essas carências influenciavam as questões de recuperação de dados e no funcionamento da rede em caso de falhas. Logo, este trabalho adiciona suporte ao recurso de replicação de informações fornecido pelo banco de dados MongoDB utilizado pela arquitetura RouteFlow, e garante a tolerância a falhas, visando uma maior disponibilidade do sistema. Para tanto, são descritos e detalhados os aperfeiçoamentos feitos no projeto, e os scripts de testes utilizados. Os resultados obtidos permitem conferir ao RouteFlow maior robustez, o tornando menos vulnerável à falhas. Palavras-chave: Redes Definidas por Software. OpenFlow. RouteFlow. Escalabilidade. Resiliência.

8 ABSTRACT This monograph proposes the improvement of the RouteFlow Project by implementing scalability and resilience in the communication between the modules of the architecture. To achieve these goals we introduce the concept of OpenFlow, an open API for programming the forwarding plane of switches, which in recent years has been calculating the behavior of network applications through applications. Motivated by the visibility of Software-Defined Networking CPqD developed the RouteFlow project, an open architecture that enables virtualization of IP routing operations in OpenFlow networks, through an effective separation of the control plane and the forwarding plane of routing in network equipments, which seeks to combine the high performance of off-the-shelf hardware (commodities) with the flexibility of a routing stack remotely executed on general purpose computers. However, until the completion of this monograph, the way that the database was implemented in RouteFlow did not allow the replication of the database and, moreover, its failover was not configured in an automated manner. These shortcomings influenced the issues of data recovery and network operation in the event of failures. Therefore, the aim of this work is to add support to the replication of the information resource provided by the MongoDB database used by the RouteFlow architecture, and ensure fault tolerance to ensure greater system availability. In that sense, are described and detailed the enhancements made in the project, and test scripts used. The results obtained give the RouteFlow greater robustness, making it less vulnerable to failures. Key-words: Software-Defined Network. OpenFlow. RouteFlow. Scalability. Resilience.

9 LISTAS DE FIGURAS FIGURA 1 Arquiteturas de roteamento FIGURA 2 Escopo da arquitetura do switch OpenFlow FIGURA 3 Campos do cabeçalho OpenFlow para a especificação de fluxos FIGURA 4 Representação Arquitetura RouteFlow FIGURA 5 Principais Módulos da Arquitetura RouteFlow FIGURA 6 Cenário Típico da Arquitetura RouteFlow FIGURA 7 Diagrama de uso do MongoIpc pelos componentes do RouteFlow FIGURA 8 Diagrama da estrutura base criada para operação com o banco FIGURA 9 Tratamento de erros em Python e C

10 LISTAS DE TABELAS TABELA 1 Resultados obtidos na arquitetura pré implementação TABELA 2 Resultados obtidos na arquitetura pós implementação... 40

11 LISTAS DE ABREVIATURAS E SIGLAS API Application Programming Interface ARP Address Resolution Protocol BGP Border Gateway Protocol CPqD Centro de Pesquisa e Desenvolvimento em Telecomunicações GUI Graphical User Interface IP Internet Protocol IPC Inter-Process Communication JSON JavaScript Object Notation MPLS Multi Protocol Label Switching NDDI Network Development and Deployment Initiative OSPF Open Shortest Path First RDS Redes Definidas por Software REST Representational State Transfer RIP Routing Information Protocol SDN Software-Defined Network SNMP Simple Network Management Protocol SSL Secure Socket Layer TCP Transmission Control Protocol UDP User Datagram Protocol VM Virtual Machine

12 SUMÁRIO 1 INTRODUÇÃO REDES DEFINIDAS POR SOFTWARE OPENFLOW HISTÓRICO DEFINIÇÃO PROTOCOLO OPENFLOW ARQUITETURA OPENFLOW ROUTEFLOW HISTÓRICO DEFINIÇÕES PROTOCOLO ROUTEFLOW ARQUITETURA ROUTEFLOW Módulos da arquitetura RouteFlow Alguns avanços da arquitetura RouteFlow BANCO DE DADOS CENTRALIZADO COM SUPORTE A IPC MONGODB TRATAMENTO DE ERROS NO IPC ESTRUTURA ATUAL DO CÓDIGO ALTERAÇÕES REALIZADAS TESTES E RESULTADOS CONCLUSÕES REFERÊNCIAS APÊNDICE A EXAMPLEPROTOCOL.CC APÊNDICE B EXAMPLEPROTOCOL.H APÊNDICE C INIT_MONGO_REPLICATION.SH APÊNDICE D TEST_IPC_MONGO.CC APÊNDICE E EXAMPLEPROTOCOL.PY APÊNDICE F TEST_IPC_MONGO.PY... 55

13 12 1 INTRODUÇÃO Atualmente as redes de computadores permeiam todos os setores da sociedade. Por meio destas, grande parte das informações geradas ao redor do mundo são transmitidas. Pode-se destacar a internet, que passou a ser a rede mais utilizada globalmente, como ferramenta para o desenvolvimento de muitas atividades cotidianas. Dessa forma a rede mundial de computadores recebe um tráfego de informações gigantesco, fazendo com que a estabilidade e o fácil acesso se tornem características fundamentais para as atuais redes. Segundo Sherwood et al. 1 (2010 apud NASCIMENTO et al., 2011, p ), as redes de computadores atingiram um nível de amadurecimento que as tornaram pouco flexíveis, o que acabou prejudicando os trabalhos de pesquisa nesta área com novas tecnologias e protocolos, já que estes não são mais possíveis devido ao risco de interrupções ou instabilidade dos serviços essenciais utilizados em larga escala. Ainda segundo os autores, outro problema gerado foi a inviabilização de novas tecnologias que tenham como exigência a inserção de equipamentos de hardware. Tentando melhorar o cenário atual, a comunidade de pesquisa em redes de computadores tem investido em iniciativas que proporcionam o desenvolvimento de redes com maiores recursos de programação, de modo que novas tecnologias possam ser inseridas de forma gradual, sem interferir no funcionamento da rede. Uma das formas encontradas para propiciar este desenvolvimento foi a separação entre o plano de dados, também chamado plano de encaminhamento, responsável pela comutação e repasse dos pacotes de rede, e o plano de controle que cuida dos protocolos e das tomadas de decisão que resultam na confecção das tabelas de encaminhamento, os quais normalmente são encontrados juntos em um mesmo dispositivo de rede. Tal separação permite que a operação que precisa de alto desempenho nos elementos de comutação atual (encaminhamento de pacotes) permaneça pouco alterada, de modo a manter a viabilidade de desenvolvimento de hardware, enquanto que a decisão sobre o destino de cada pacote possa ser 1 SHERWOOD, Rob et al. Can the Production Network be the Testbed?. In: 9th USENIX Conference on Operating Systems Design and Implementation (OSDI'10). 2010, Vancouver, Canada. Proceedings... Berkeley, CA, USA: USENIX Association, p

14 13 transferida para o nível de controle, onde diferentes funcionalidades podem ser implementadas. Isto permite o controle extensível das redes através de aplicações, expressas em software. Surge então, um novo paradigma na área de redes de computadores, que recebe o nome de Redes Definidas por Software (Software Defined Network SDN), adotado como a principal ferramenta de simulação ou aplicação para ambientes reais. A iniciativa mais bem sucedida nesse sentido foi sem dúvida, a definição da interface e do protocolo OpenFlow (MCKEOWN et al., 2008) proposto pela Universidade de Stanford para atender à demanda de validação de novas propostas de arquiteturas e protocolos de rede sobre equipamentos comerciais. O OpenFlow apresenta-se como um protocolo de padrão aberto e generalizado, que implementa uma separação clara e efetiva do plano de controle e do plano de encaminhamento do dispositivo de rede, permitindo que redes reais sejam utilizadas em experimentos sem haver interferência em seu funcionamento. Foi a partir desta perspectiva que o Projeto comunitário, conhecido como RouteFlow surgiu. Liderado pelo Centro de Pesquisa e Desenvolvimento (CPqD), o RouteFlow compreende uma plataforma de roteamento IP definida por software e tem como objetivo tornar as redes IP flexíveis. Segundo Nascimento et al. (2011, p ), o RouteFlow é uma proposta de roteamento remoto centralizado que visa o desacoplamento entre o plano de encaminhamento e o plano de controle, tornando as redes IP mais flexíveis pela facilidade da adição, remoção e especialização de protocolos e algoritmos. No caso, o RouteFlow move a lógica de controle dos equipamentos de rede, até então embarcada, para um controlador de rede remoto cuja responsabilidade é tomar decisões de encaminhamento e programar os elementos do plano de encaminhamento para aplicar essas decisões. Tem-se na arquitetura RouteFlow alguns elementos muito importantes que necessitam ser escaláveis e resilientes devido as exigências das atuais redes de grande porte. Um desses elementos é o banco de dados, que armazena inúmeras visões do estado da rede recebidas do controlador, que por sua vez é o software responsável por tomar decisões e adicionar e remover as entradas na tabela de fluxos. O banco de dados utilizado atualmente é o MongoDB, que implementa o mecanismo de troca de mensagens entre processos denominado Inter Process

15 14 Communication (IPC), permitindo configurações escaláveis por milhares de nós, com balanceamento de carga e failover automáticos, sem ponto único de falha. No entanto, o modo como o banco de dados está implementado atualmente na arquitetura RouteFlow não possibilita a replicação da base de dados, pois não fornece meios de recuperação dos dados armazenados caso ocorra algum erro na instância principal. Além disso, neste componente da arquitetura, o failover não está configurado de maneira automatizada, o que interferirá gravemente no funcionamento da rede no caso de ocorrência de falhas como, por exemplo, a perda de conexão com a base de dados, ou a corrupção de informações armazenadas no mesmo. O objetivo principal deste trabalho é implementar duas novas funcionalidades de extrema importância no Projeto RouteFlow, que são a escalabilidade e a resiliência, visando aprimorar a operabilidade do projeto. Para tanto, no banco de dados, pretende-se promover a flexibilização da quantidade de nós do sistema, e garantir a tolerância a falhas, respectivamente. Redes Definidas por Software constituem uma tecnologia recente, e a arquitetura RouteFlow busca se destacar como uma plataforma estável e confiável, para ser utilizada pelos mais exigentes mercados. Agregando as funcionalidades objetos deste trabalho à plataforma, a transformará em um sistema confiável, competitivo e maduro, fazendo com que este modelo de roteamento seja adequado às propostas vigentes no mercado de redes de grande porte atual. Esta monografia está dividida em oito capítulos. Seguindo esta Introdução, iniciam-se as revisões bibliográficas com o Capítulo 2, Redes Definidas por Software, que trata da quebra de paradigma do modelo tradicional de encaminhamento de pacotes, pelo modelo com separação de plano. Seguindo, o Capítulo 3, OpenFlow, fala sobre a criação do protocolo que originou as Redes Definidas por Software, e seu respectivo funcionamento. No Capítulo 4, RouteFlow, é abordado a arquitetura e seus componentes, especialmente na comunicação entre seus módulos. Também são abordados pontos históricos, e contribuições privadas e acadêmicas para o projeto. E no Capítulo 5, MongoDB, o enfoque é para o banco de dados da arquitetura RouteFlow, esclarecendo como é o tratamento dos dados, e assim encerrando as revisões bibliográficas.

16 15 Em seguida, no Capítulo 6, Tratamento de Erros no IPC, é iniciado as descrições sobre a nova implementação, onde são apresentadas as análises dos códigos, os detalhes internos de operação, o esquemático da arquitetura proposta, as alterações realizadas, bem como os detalhes das etapas de desenvolvimento da nova feature para o projeto. Já no Capítulo 7, Testes e Resultados, são apresentados os resultados mais importantes obtidos, incluindo uma breve descrição dos códigos e do roteiro de teste executado. Por fim, o Capítulo 8, Conclusões, destaca as ideias marcantes obtidas durante o desenvolvimento deste trabalho, e as contribuições que o mesmo proporcionou ao Projeto RouteFlow. Nos Apêndices são encontrados os códigos desenvolvidos e utilizados para a configuração do sistema e para a etapa de teste.

17 16 2 REDES DEFINIDAS POR SOFTWARE Atualmente a infraestrutura das redes de pacotes é composta por equipamentos proprietários, fechados e de custo elevado, cujas arquiteturas básicas são constituídas pela combinação de circuitos dedicados, e por uma camada de software de controle. Observando-se a arquitetura em vigor dos roteadores, à esquerda da FIGURA 1, é constatado que se trata de um appliance formado basicamente por essas duas camadas bem distintas: o hardware (Plano de Dados), dedicado ao processamento de pacotes e responsável por garantir o alto desempenho, e o software de controle (Plano de Controle), encarregado de tomar as decisões de roteamento e as transfere para o plano de encaminhamento através de uma API (Application Programming Interface) embarcada e proprietária. A única interação da gerência com o dispositivo ocorre através de interfaces de configuração (e.g. Web), limitando o uso dos dispositivos às funcionalidades programadas pelo fabricante. Mas de acordo com Nascimento et al. (2011), para cada tipo e objetivo de rede, especialmente as redes corporativas, tem-se a necessidade de especialização da lógica de controle destes equipamentos. Entretanto, conforme esclarece Hamilton 2 (2009, apud ROTHENBERG et al., 2010, p. 65), qualquer mudança de configuração avançada do equipamento ou especialização da lógica de controle e tratamento dos pacotes ou, ainda, inserção de novas funcionalidades estão sujeitas a ciclos de desenvolvimento e de testes restritos ao fabricante do equipamento, resultando em um processo demorado e custoso. As redes de computadores são uma realidade cotidiana como, por exemplo, a internet, com sua evolução formidável em termos de penetração, que vem fazendo grande parte da sociedade contemporânea dependente da alta disponibilidade de seus serviços. Porém o sucesso dessa tecnologia acarreta sintomaticamente um problema quanto à inovação, já que pesquisas com novas tecnologias e protocolos são inviáveis devido ao risco de interrupções ou instabilidade nos serviços já estabelecidos. 2 HAMILTON, James. Networking: The Last Bastion of Mainframe Computing Disponível em: < NetworkingTheLastBastionOfMainframeComputing.aspx> Acesso em: 31 jan

18 Complementado a descrição do problema em arquiteturas de rede, segundo informam Anwer et al. 3 (2010 apud ROTHENBERG et al., 2010, p. 65), 17 a ausência de flexibilidade no controle do funcionamento interno dos equipamentos assim como o alto custo da infraestrutura vigente são barreiras para a evolução das arquiteturas e para a inovação decorrente da oferta de novos serviços e aplicações de rede. Com o objetivo de quebrar o paradigma do engessamento da infraestrutura das redes, conforme relata Lucena (2011), faz-se necessária uma forma de permitir que os roteadores cuja arquitetura é composta por duas camadas autocontidas e, portanto, não necessitam estar confinadas em um mesmo dispositivo sejam programados remotamente através de APIs independentes do fabricante do equipamento, movendo a lógica de tomada de decisões para controladores externos, como um servidor dedicado e com alta capacidade de processamento (à direita da FIGURA 1). Fonte: Rothenberg et al. (2010). FIGURA 1 Arquiteturas de roteamento Mediante o encaminhamento de pacotes a partir de protocolos implementados externamente, de maneira que o plano de controle seja 3 ANWER, Muhammad Bilal et al. SwitchBlade: A Platform for Rapid Deployment of Network Protocols on Programmable Hardware. In: ACM SIGCOMM 2010 Conference (SIGCOMM 10). 2010, New Delhi, India. Proceedings... New York, USA: ACM, p

19 18 independente daquele pré-configurado, e não se limitando aos protocolos implementados pelo fabricante, mantem-se o alto desempenho no encaminhamento de pacotes em hardware, aliado à flexibilidade de se inserir, remover e especializar aplicações em software por meio de um protocolo aberto para programação da lógica do equipamento e, consequentemente, de baixo custo (LUCENA, 2011; ROTHENBERG et al., 2010). Com esse intuito originou-se a mais bem sucedida iniciativa nesse sentido, a definição da interface e do protocolo OpenFlow (MCKEOWN et al., 2008), dando origem ao que recentemente vem atraindo a atenção tanto da comunidade científica quanto da indústria de redes de computadores, que é o conceito de Redes Definidas por Software, do inglês Software-Defined Networking (SDN).

20 19 3 OPENFLOW 3.1 HISTÓRICO O OpenFlow utiliza a separação de planos de switches Ethernet modernos e, por meio de interfaces padronizadas fornecidas por estes dispositivos, é capaz de alterar o comportamento da rede manipulando as tabelas de fluxo no plano de dados, através de um protocolo definido por sua API, e através de ações que atuam sobre o fluxo de pacotes que passa pelo switch (PROJETO REVIR, 2011). Segundo Rothenberg et al. (2010), com a consolidação das tecnologias de switches programáveis no padrão OpenFlow, o conceito de SDN envolve novos paradigmas de gerência integrada, inovação em protocolos e serviços baseados em recursos de redes virtualizados. De acordo com Marques (2012, p. 21), o protocolo OpenFlow é uma das vertentes do conceito de SDN, apresentado em (MCKEOWN et al., 2008) e tem origem nos trabalhos SANE (CASADO et al. 4, 2006) e Ethane (CASADO et al. 5, 2007). O primeiro buscava melhorar a segurança da rede através da centralização das decisões de encaminhamento e acesso por um servidor central, já o segundo foi uma das primeiras arquiteturas de SDN e que por ventura se tornaria este protocolo. Fatores que contribuem para aceitação do protocolo OpenFlow, são que este padrão pode ser incorporado em roteadores, switches e pontos de acesso Wi-Fi através de atualização do firmware e sem nenhuma modificação do hardware. Os controladores remotos do plano de encaminhamento do OpenFlow são baseados em servidores com sistemas operacionais e linguagens de programação comumente utilizados na área de Tecnologia da Informação. A operabilidade desta arquitetura permite a definição de fatias de rede (slices ou flow-spaces), com garantia de isolamento entre os diferentes controladores que operam sobre a rede, permitindo que tráfegos distintos, como um operacional e um experimental, possam operar em paralelo. E importante destacar que sistema é compatível com a Internet atual, sobre 4 CASADO, Martin et al. SANE: A Protection Architecture for Enterprise Networks. In: 15th USENIX Security Symposium (Security '06). Aug. 2006, Vancouver, Canada. Proceedings... Berkeley, CA, USA: USENIX Association, p Ethane: Taking Control of the Enterprise. ACM SIGCOMM Computer Communication Review, [S.l.], v. 37, n. 4, p. 1 12, Aug. 2007

21 20 a qual o tráfego pode continuar em operação em um ou mais flow-spaces (ROTHENBERG et al., 2010). A capacidade de separação de fluxos, agregada à capacidade de limitar a área de atuação das aplicações e o acesso destas às tabelas de fluxos dos equipamentos, são características encontradas apenas no padrão OpenFlow, e convergem em uma vantagem em relação à outras tecnologias similares (PROJETO REVIR, 2011). 3.2 DEFINIÇÃO O OpenFlow fornece um protocolo aberto para programar as tabelas de fluxo de em diferentes switches e roteadores. Um administrador de redes pode particionar as tabelas em fluxos de produção e pesquisa. Os pesquisadores podem controlar seus próprios fluxos, escolhendo as rotas que seus pacotes seguem e o processamento que recebem. Desta forma, os pesquisadores podem experimentar novos protocolos de roteamento, modelos de segurança, esquemas de endereçamento, e até mesmo alternativas para IP. Na mesma rede, o tráfego de produção é isolado e processado da mesma maneira que hoje (MCKEOWN et al., 2008). Ainda segundo McKeown et al. (2008), o datapath (caminho de dados) de um switch OpenFlow consiste em um fluxo de tabela, e uma ação associada a cada entrada de fluxo. Acrescenta Fernandes (2011, p ), o OpenFlow não assume o uso de um plano de dados virtualizado sobre os elementos de encaminhamento e, consequentemente, segue o modelo de um único plano de dados compartilhado para todas as redes. 3.3 PROTOCOLO OPENFLOW O OpenFlow define um protocolo-padrão para determinar as ações de encaminhamento de pacotes em dispositivos de rede. As regras e ações instaladas

22 21 no dispositivo da rede são responsabilidade do controlador externo, que pode ser implementado em um servidor comum inclusive (ROTHENBERG et al., 2010). Conforme salienta Corrêa (2012), a concepção original do OpenFlow não deixa dúvida de que se trata de um protocolo. Observando o contexto de redes baseadas em sua operação, equipamentos que desempenhavam funções de controle passaram a tê-las eliminadas ou redirecionadas, mudando sua natureza, e estabelecendo um modelo operacional específico, pelo qual o OpenFlow também pode ser designado como uma arquitetura. Conclui o autor que, as mudanças empreendidas pressupõem a capacidade de se alterar e inovar via software as próprias funções constituídas a partir do modelo. E pelo fato de serem desenvolvidos para desempenhar uma função bem definida, e baseados em paradigmas e interfaces padronizados, tais softwares implicam na modificação da dinâmica de agregação de valor às redes de computadores anteriormente orientada à inovação baseada em hardware, mais custosa e menos comoditizada. Sob esta ótica mais ampla, OpenFlow torna-se um ecossistema (CORRRÊA, 2012, p. 15). 3.4 ARQUITETURA OPENFLOW A arquitetura de SDN OpenFlow generaliza a função desempenhada pelos switches chamando-os de datapaths. Cada datapath, ao receber um pacote de dados para encaminhamento, baseia sua decisão em entradas de uma tabela de fluxos, que possui colunas que descrevem possíveis características das unidades de tráfego a serem encaminhadas, fazendo uso de campos dos cabeçalhos das diversas camadas de comunicação. Visto que a lógica de decisão dos dispositivos controladores pode ser implementada como software, e se basear em combinações arbitrárias de campos de cabeçalhos, a arquitetura OpenFlow pode viabilizar a inovação, experimentação e operacionalização de ideias em redes de computadores (CORRÊA et al., 2012). Redes programáveis com OpenFlow consistem nos seguintes componentes (FIGURA 2) habilitados nos equipamentos (ROTHENBERG et al., 2010): Tabela de Fluxos: Cada entrada na tabela de fluxos do hardware de rede consiste em regra, ações e contadores. A regra é formada com base na definição do valor de um ou mais campos do cabeçalho do pacote. Associa-se a ela um conjunto de ações que definem o modo como os

23 22 pacotes devem ser processados e para onde devem ser encaminhados. Os contadores são utilizados para manter estatísticas de utilização e para remover fluxos inativos. As entradas da tabela de fluxos podem ser interpretadas como decisões em cache (hardware) do plano de controle (software), sendo, portanto, a mínima unidade de informação no plano de dados da rede. Canal Seguro: Para que a rede não sofra ataques de elementos malintencionados, o canal seguro garante confiabilidade na troca de informações entre o switch e o controlador. Protocolo OpenFlow: Protocolo aberto para comunicação que usa uma interface externa, definida pelo OpenFlow para a troca de mensagens entre os equipamentos de rede e os controladores. Controlador: É o software responsável por tomar decisões e adicionar e remover as entradas na tabela de fluxos, de acordo com o objetivo desejado. O controlador exerce a função de uma camada de abstração da infraestrutura física, facilitando a criação de aplicações e serviços que gerenciem as entradas de fluxos na rede. Fonte: McKeown et al. (2008) FIGURA 2 Escopo da arquitetura do switch OpenFlow

24 23 Quando um pacote de rede chega a um switch OpenFlow, os cabeçalhos são comparados às regras das entradas das tabelas de fluxos, os contadores são atualizados e as ações correspondentes são realizadas (FIGURA 3). Caso não haja correspondência entre o pacote e alguma entrada da tabela de fluxos, o pacote é encaminhado, por completo, ao controlador. (ROTHENBERG et al., 2010). Fonte: Rothenberg et al. (2010). FIGURA 3 Campos do cabeçalho OpenFlow para a especificação de fluxos O modelo da arquitetura OpenFlow tem sido utilizado como base em diversos experimentos, mas ainda carece de um melhor desempenho. Desenvolvido para suprir essa lacuna, o Open vswitch é um switch virtual que segue a arquitetura OpenFlow, implementado em software, com o plano de dados dentro do kernel do sistema operacional Linux, enquanto o plano de controle é acessado a partir do espaço do usuário. Essa implementação foi desenvolvida para controlar o tráfego de rede em ambientes virtualizados, emulando as interfaces de rede do sistema Linux, e utilizando partes do código fonte de seu próprio módulo bridge, que implementa o switch de rede padrão do Linux (NUNES, 2012).

25 24 4 ROUTEFLOW 4.1 HISTÓRICO O surgimento do projeto comunitário RouteFlow deu-se através da quebra de uma paradigma, acima citado, Redes Definidas por Software (SDN) e também, pela definição da interface e do protocolo OpenFlow, onde a consulta a tabela de encaminhamento continua sendo tarefa do hardware, mas a decisão sobre como cada pacote deve ser processado pode ser transferida para o nível de software (NASCIMENTO, 2012). O projeto é uma proposta de oferta de serviços de roteamento IP remoto de forma centralizada, e que visa um desacoplamento efetivo entre o plano de encaminhamento e o plano de controle (ROUTEFLOW PROJECT, 2013). O Objetivo é tornar as redes IP mais flexíveis pela facilidade de adição, remoção e especialização de protocolos e algoritmos (NASCIMENTO, 2012). Segundo Vidal et al. (2013), o projeto RouteFlow conta com uma base de usuários crescente em todo o mundo (mais de 1000 downloads e mais de visitantes, desde que o projeto começou em abril de 2010). As contribuições externas variam de relatórios de erros para submissões de código via repositório GitHub (orientado à comunidade). Para citar alguns exemplos, o Google tem contribuído com um plug-in SNMP e está atualmente trabalhando em apoio ao MPLS e novas APIs do Quagga. A Universidade de Indiana acrescentou um GUI avançado para executar os pilotos nos switches no US-wide NDDI testbed. A UNIRIO tem um protótipo da abstração de um único nó com um grande controlador de domínio ebgp. A UNICAMP fez uma porta para o Ryu Controlador OpenFlow 1.2 e está fazendo experiências com novos projetos de data center. Enquanto alguns usuários estão experimentando o RouteFlow com Quagga on Steroids para alcançar uma solução acelerada por hardware através de roteamento open source, outros estão olhando para os projetos rentáveis de ponta BGP-frees em cenários híbridos de redes IP-SDN onde o RouteFlow oferece um caminho de migração para OpenFlow / SDN. Estes são exemplos de inovação que estão em andamento, resultantes da mistura de interfaces abertas de hardware comercial e de código aberto

26 25 impulsionando o desenvolvimento de software da comunidade. A principal meta do RouteFlow é desenvolver um framework de código aberto para soluções de roteamento IP virtual sobre commodity (bens e serviços) de hardware que implemente a API OpenFlow. O RouteFlow visa uma arquitetura de roteamento commodity com a flexibilidade das pilhas de roteamento de código aberto executando (remotamente) em computadores de propósito geral (ROUTEFLOW PROJECT, 2013). 4.2 DEFINIÇÕES Segundo Nascimento (2012), o RouteFlow prove um serviço virtualizado de roteamento IP em equipamentos com suporte ao protocolo OpenFlow seguindo o paradigma das redes definidas por software. Basicamente, o RouteFlow interliga uma infraestrutura OpenFlow com um ambiente virtual de roteamento IP baseado em ferramentas nativas do Linux (Quagga) para um roteamento eficiente na estrutura física. Baseado em um sistema de controle RouteFlow, os switches são instruídos via controladores OpenFlow que trabalham como proxies no intuito de traduzir as mensagens e eventos entre o ambiente físico e virtual. 4.3 PROTOCOLO ROUTEFLOW De acordo com Nascimento (2012), o protocolo RouteFlow é um protocolo desenvolvido usado para a comunicação entre os componentes do RouteFlow. Nele, estão definidas as mensagens e os comandos básicos para conexão e configuração das máquinas virtuais e, também, gerenciamento das entradas de roteamento em hardware. Entre os campos da mensagem-padrão estão: identificação do controlador, identificação da máquina virtual, tipo da mensagem, comprimento e dados. O protocolo RouteFlow também comunica-se com o protocolo OpenFlow isso acontece por meio do proxy (RFProxy) que recebe os comandos do servidor (RFServer) através deste protocolo e de acordo com o tipo de comando executa as principais ações, muitas delas exigindo a comunicação com os switches físicos. A

27 comunicação com os switches físicos é feita via protocolo OpenFlow, fazendo o proxy RouteFlow agir como uma espécie de tradutor entre os dois protocolos ARQUITETURA ROUTEFLOW Segundo Nascimento et al. (2011), na arquitetura RouteFlow, o plano de controle é formado por protocolos de roteamento IP de código aberto. O plano de roteamento é constituído de máquinas virtuais (VMs) conectadas de forma a representar, através de uma topologia lógica de roteamento, a topologia física da rede controlada. Como pode ser visualizada na FIGURA 4. Fonte: < FIGURA 4 Representação Arquitetura RouteFlow Na topologia lógica virtual, cada VM roda um mecanismo de roteamento padrão, ou seja, o mesmo software de controle que estaria embarcado em um roteador. As interfaces das VMs representam as portas do roteador e que se conectam a um software que simula um switch, onde é possível configurar o fluxo e promover as devidas conexões entre as VMs. Ainda por meio dos fluxos podem-se configurar quais pacotes devem permanecer na rede virtual e quais devem ir para o plano de encaminhamento. (NASCIMENTO et al., 2011).

28 Módulos da arquitetura RouteFlow O RouteFlow é composto basicamente por três módulos principais (FIGURA 5), conforme descrição a seguir (NASCIMENTO, 2012): Cliente RouteFlow (RFClient): executa um programa executável em uma VM, detectando mudanças na tabela ARP do Linux e na tabela de roteamento. Servidor RouteFlow (RFServer): é uma aplicação independente que gerencia as máquinas virtuais que estão executando o Cliente RouteFlow (RFClient), ou seja, é ele que mantem o mapeamento entre as instâncias das VMs executando o cliente (RFClient) e as interfaces correspondentes aos switches e suas respectivas portas. O RFServer também é conectado ao proxy RouteFlow (RFProxy) para instruí-lo como configurar os fluxos e como configurar o Open vswitch (programa que simula um switch físico) que mantem a conectividade de todo o ambiente composto pelas VMs. Este é o módulo mais complexo e importante do Projeto RouteFlow. Proxy RouteFlow (RFProxy): é uma aplicação responsável pelas interações entre os switches OpenFLow (identificados pelos seus datapaths) via protocolo OpenFLow e os demais módulos do ambiente, como o servidor (RFServer) e o conjunto de clientes (RFClients). Ele aguarda instruções do servidor (RFServer) e o notifica à respeito de todos os eventos da rede. Banco de Dados (BD): é usado como ponto central de um mecanismo de troca de mensagens entre processos (IPC) e consequentemente manter o histórico das ações tomadas pelo RouteFlow para permitir a replicação de certas situações. Ou seja, a confiabilidade do mapeamento entre o ambiente físico controlado e o ambiente virtual executando as tarefas de roteamento se torna difícil de manter sem a ajuda de algum módulo externo, sendo que o Banco de dados se encarrega desse objetivo, tendo sua configuração mais flexível. (NASCIMENTO, 2012).

29 28 Fonte: < FIGURA 5 Principais Módulos da Arquitetura RouteFlow Os mecanismos de roteamento em ambiente virtual geram uma base de informação de encaminhamento baseado nos protocolos de roteamento (OSPF, BGP) e processos ARP. Durante a execução do ambiente virtual, as tabelas de roteamento e tabelas ARP são coletadas pelos módulos clientes (RFClient) executado nas VMs e traduzido em tuplas OpenFlow, assim que atualizadas pelas aplicações encarregadas do roteamento (Quagga), são enviadas para o servidor (RFServer), que faz a adaptação das informações para o ambiente físico e finalmente instrui o módulo proxy (RFProxy), uma aplicação controladora, para configurar os switches OpenFlow no ambiente físico (NASCIMENTO, 2012). O autor acrescenta que os pacotes de encaminhamento dos protocolos de

30 29 roteamento e controle de tráfico (ARP, BGP, RIP e OSPF) são direcionados pelo proxy (RFProxy) para as interfaces virtuais correspondentes do ambiente virtual. Entre o ambiente virtual e o ambiente existe um switch virtual que também é controlado pelo proxy (RFProxy), permitindo um caminho direto entre os ambientes, reduzindo o tempo das trocas de mensagens e sem a necessidade de passar através do servidor (RFServer) e do cliente (RFClient) (NASCIMENTO, 2012). Por fim, temos o Banco de Dados (BD) que realiza a troca de mensagens (através do protocolo RouteFlow) entre todos os módulos da arquitetura RouteFlow, como mostrado na FIGURA 6. Fonte: < FIGURA 6 Cenário Típico da Arquitetura RouteFlow Alguns avanços da arquitetura RouteFlow Segundo Nascimento (2012), alguns dos principais avanços da arquitetura do projeto RouteFlow são: Possibilidade de ambientes com múltiplos controladores OpenFlow. Plataforma totalmente modular, extensível, configurável e flexível, ou seja através da construção baseada em módulos independentes o código tornou-se mais claro, facilitando a portabilidade para outras linguagens

31 30 ou o suporte à novas tecnologias. Outro benefício da construção da arquitetura por meio de módulos, é a possibilidade de execução do RouteFlow em múltiplos sistemas computacionais (arquitetura distribuída). Armazenamento do histórico da rede e de estatísticas. O RouteFlow, através do banco de dados centralizado, mantem um histórico de todos o sistema, bem como as estatísticas relacionadas à criação de regras e ao uso da rede. Tais características permitem aos pesquisadores ou até mesmos aos administradores de redes ter um controle e um entendimento mais elaborado, podendo reproduzir o ambiente em certos períodos de tempo. Suporte à replicação do estado da rede e grande disponibilidade dos recursos. O RouteFlow foi construído de forma descentralizada, separando os dados relacionados ao estado das redes dos módulos de processamento. No entanto, todos os dados relacionados ao estado das redes são armazenados em um banco de dados centralizado, possibilitando que qualquer aplicação registrada tenha acesso, obtendo a replicação dos processos. Vantagens e benefícios de um sistema descentralizado 4.5 BANCO DE DADOS CENTRALIZADO COM SUPORTE A IPC Conforme Mathilde (2013), várias abordagens foram proposta pelo RouteFlow para um esquema unificado de comunicação entre processos (IPC). Inúmeras delas foram testadas e avaliadas até se conseguir traçar as principais vantagens e desvantagens de cada uma delas. Soluções baseadas em filas de mensagens, como o RabbitMQ ou o ZeroMQ foram descartadas por causa da grande complexidade de implementação e manutenção. Para o autor, soluções baseadas em serialização de mensagens, como ProtoBuffers e Thrift, se apresentaram como boas soluções mas requeriam uma lógica adicional para o armazenamento pendente e para mensagens já consumidas. Durante o estudo de banco de dados Não SQL para armazenamento persistente, surgiu as primeiras ideias do uso de um banco de dados como ponto central de um mecanismo de troca de mensagens

32 entre processos (IPC) e consequentemente manter o histórico das ações tomadas pelo RouteFlow para permitir a replicação de certas situações (MATHILDE, 2013, p. 20). A escolha de delegar o controle dos estados da rede para um banco de dados permite uma melhor tolerância a falhas, replicando a base de dados ou até mesmo separando o servidor (RFServer) em várias instâncias. A possibilidade de distribuição do servidor (RFServer) permite ao sistema um melhor desempenho, sendo possível distribuí-lo em vários pontos de uma rede e assim reduzindo a latência de comunicação. Além de que as estatísticas coletadas pelo proxy (RFProxy) também podem ser armazenadas neste banco, baseado em serviços adicionais e é até possível implementar ferramentas para análise dos dados ou até mesmo visualização. De acordo com Mathilde (2013, p. 20), 31 depois de levar em consideração as mais populares opções de banco de dados Não SQL (MongoDB, Redis, CouchDB), foi decidido sobre a implementação de um banco de dados centralizado e dos mecanismos de troca de mensagens entre processos (IPC) utilizando-se o MongoDB. Os principais fatores para a escolha foram a facilidade de programação, suporte nativo a inúmeras linguagens de programação, suporte nativo a tecnologia JSON e a existência de mecanismo para replicação e distribuição. O RouteFlow apresenta uma arquitetura adequada ao processo de replicação de dados, com a utilização de uma base de dados para armazenar os estados da rede, bastando adicionar as funcionalidades de replicação e sincronismo do banco de dados, para garantir a integridade dos dados, que dessa forma estariam protegidos contra falha dos servidores de armazenamento, almejando assim a confiabilidade por meio da alta disponibilidade do sistema.

33 32 5 MONGODB O MongoDB é um banco de dados de software livre escrito na linguagem C++, que ao contrário dos tradicionais bancos de dados que utilizam o modelo relacional, utiliza um modelo de dados orientado a documentos sendo enquadrado no conceito de NoSQL no qual seus dados são armazenados em coleções de documentos BSON versão binária do JSON que retém estes utilizando pares de chave/valor. O banco possui versões para os principais sistemas operacionais e drivers para diversas linguagens de programação. De acordo com Lennon (2011) as diferenças entre o modelo orientado a documentos, utilizado pelo MongoDB, e modelo relacional são muito diferentes, dadas as divergências do modo como cada um trabalha com os dados. Os bancos de dados orientados a documentos são bastante diferentes dos tradicionais bancos de dados relacionais. Em vez de armazenar dados em estruturas rígidas, como tabelas, eles os armazenam em documentos vagamente definidos, possuindo um design de bancos de dados onde geralmente não há esquemas. Outra diferença fundamental é que bancos de dados orientados a documentos não fornecem relacionamentos estritos entre documentos, de tal forma que ao invés de armazenar dados relacionados em uma área separada, estes sejam integrados ao próprio documento. Isso é muito mais rápido do que armazenar uma referência a outro documento onde os dados relacionados são armazenados, visto que cada referência exigiria uma consulta adicional. O banco de dados MongoDB utiliza para a replicação de informações um modelo similar ao modelo Mestre-Escravo, denominado Replica Set. Um Replica Set no MongoDB é um cluster de instâncias do mongod que se replicam entre si e garantem failover automático. A maioria dos Replica Sets consistem de duas ou mais instâncias do mongod. Os clientes direcionam todas as operações de escrita ao membro primário, enquanto que os membros secundários fazem a replicação do primário, de forma assíncrona (MONGODB DOCUMENTATION, 2013). O mongod, como detalhado em MongoDB Documentation (2013), é um processo daemon que manipula requisição de dados, gerenciando o formato dos mesmos, e executa operações de gerenciamento da base de dados, em segundo plano.

34 33 Conforme MongoDB Documentation (2013), são evidenciadas as semelhanças entre o modelo de replicação utilizado pelo MongoDB e o modelo de replicação mestre-escravo. Pode-se pensar no Replica Set como uma forma mais sofisticada da tradicional replicação mestre-escravo. Na replicação mestre-escravo, o nó mestre aceita escritas enquanto que um ou mais nós escravos replicam estas operações de escrita e assim mantém os conjuntos de dados idênticos aos do mestre. Para as implementações do MongoDB, o membro que aceita operações de escrita é denominado primário, e os membros que efetuam a replicação destas operações, secundários. Os benefícios da utilização da replicação da base de dados são, dentre outros, a redundância, o auxílio na garantia de alta disponibilidade, a simplificação de determinadas tarefas administrativas (i.e. Backup) e a possibilidade de aumento da capacidade de leitura. Isto faz com que a utilização da replicação seja utilizada na maioria das implementações deste banco em um ambiente de produção (MONGODB DOCUMENTATION, 2013). O fato dos Replica Sets apresentarem o failover automático implica que em caso de o membro primário ficar off-line ou deixar de responder as requisições, um novo primário será eleito, com a condição de que a maioria dos demais membros do conjunto possam estabelecer conexões entre si. Segundo MongoDB Documentation (2013), as eleições permitem ao Replica Set se recuperar de situações de failover muito rapidamente e robustamente, já que proporcionam um mecanismo através do qual os membros do conjunto possam eleger, autonomamente, um novo primário, não requerendo a intervenção de um administrador. O funcionamento das eleições no MongoDB é explicado, evidenciando-se que está ocorre toda vez que o membro primário torna-se indisponível, já que faz-se necessário a seleção do membro que assumirá esta posição. O primeiro membro a receber votos da maioria dos membros do conjunto, se tornará o primário. A característica mais importante das eleições no Replica Set é que a maioria do número de membros original de um Replica Set precisa estar presente para que a eleição tenha sucesso. Ainda conforme a explicação do mesmo documento, em caso de falhas, o tempo de failover do Replica Set é normalmente de um minuto, sendo que o primário é declarado inacessível e uma eleição é disparada após 10 a 30 segundos da ocorrência da falha, e a eleição é concluída dentro de outros 10 a 30 segundos.

35 34 6 TRATAMENTO DE ERROS NO IPC Antes de qualquer alteração no código, foi realizada uma análise da estrutura atual do código do projeto, com foco principalmente na parcela relacionada ao IPC, de forma a compreender o funcionamento do mesmo, para então planejar as alterações necessárias de forma a atingir o objetivo deste trabalho. Durante esta análise, observou-se que os módulos que compõem o projeto são escritos em duas linguagens de programação diferentes: Python e C++. Os módulos RFServer e RFProxy são escritos em linguagem Python, enquanto o módulo RFClient é escrito em C++. Assim sendo, o IPC está implementado nas duas linguagens, de forma a permitir que todos os módulos possam enviar e receber mensagens, uns dos outros. Ambas as implementações seguem o mesmo modelo de IPC, utilizando os conceitos de programação orientada a objetos, com as diferenças é claro, das particularidades impostas por cada linguagem de programação. 6.1 ESTRUTURA ATUAL DO CÓDIGO Todas as mensagens transmitidas através do IPC possuem um tipo prédeterminado. Cada um desses tipos de mensagem é definido em uma classe que deve possuir métodos para exportar e importar seus dados para a estrutura de dados BSON versão binária do JSON, utilizada principalmente pelo banco de dados MongoDB e um método que retorne o seu tipo um valor inteiro único, que identifique este tipo de mensagem dentre todos os demais. Este tipo é utilizado em outras partes do código de forma a identificar com qual estrutura de mensagem se está trabalhando. Quando um dos módulos da arquitetura RouteFlow recebe uma mensagem, é necessário que esta seja processada a fim de extrair as informações relevantes da mesma, para então definir as ações a serem realizadas. Sendo assim, há uma classe base que define um padrão para todas as classes que processarão mensagens. Esta simplesmente define que todas as classes que a herdarem devem possuir um método que receba a mensagem a ser processada, e tome as decisões

36 35 necessárias com base no tipo e conteúdo da mensagem. Deste modo, cada módulo define um processador de mensagens que reage ao recebimento de determinados tipos de mensagem, realizando ações previamente definidas. Embora a estrutura do código permita diversas implementações de IPC, atualmente o RouteFlow vem com suporte nativo apenas a uma implementação, a qual utiliza o MongoDB, comumente referenciada como MongoIPC. Esta implementação fornece métodos para envio e recebimento de mensagens, para a comunicação entre os processos do RouteFlow, que utilizam as APIs do banco de dados em Python e C++. Todas as mensagens transmitidas são armazenadas no banco de dados MongoDB, sendo assim uma conexão com o mesmo é utilizada em todas as operações de leitura (recebimento de mensagens) e escrita (envio de mensagens) ao banco (FIGURA 7). Deste modo, estas operações podem não ser completadas satisfatoriamente caso ocorra alguma falha na conexão com o banco de dados, já que o código não faz tratamento destes erros. Constatado isso, pôde-se então planejar e por em prática as alterações necessárias para resolver este problema que afeta seriamente a estabilidade, segurança e disponibilidade do RouteFlow. FIGURA 7 Diagrama de uso do MongoIpc pelos componentes do RouteFlow.