Openstack-based future Internet testbed. RF Relatório Final. Autor Jean Menossi

Transcrição

1 Openstack-based future Internet testbed RF Relatório Final Autor Jean Menossi Data 15/01/2016

2 1. Introdução O projeto FIBRE2 tem um grande desafio de evolução tecnológica de sua testbed e a atração de mais usuários experimentadores, além do suporte a experimentos inovadores em uma única plataforma usando SDN, BigData, Cloud, Redes Sem Fio entre outros. Nesse contexto, com o final do projeto FIBRE, a testbed acabou ficando consolidada em 2 abordagens, a primeira de uso de CMF exclusivo para SDN/OpenFlow e a segunda CMF exclusivo para Redes Sem Fio. Sendo que o objetivo final era que ambos os CMFs pudessem ter sido integrados pelo software MySlice que opera com todo o poder do SFA Slice Federation Architecture. Entretanto, devido a natureza diferente de ambos CMFs: compartilhamento simultâneo de recursos e testes de tempo real no primeiro, e experimentos pré-programados, em recursos alocados exclusivamente e organizados por calendário no segundo, ficou complicado de ter todas as características integradas em uma única federação. Nessa prova de conceito, nossa idéia é fornecer uma arquitetura para a ilha FIBRE diferente. Usando o OPENSTACK como sistema operacional para o fornecimento de serviços de Infrastructure as a Service para os experimentadores. O OPENSTACK parece dar maior flexibilidade ao experimentador de setups que gostaria de realizar, e não ficaria restrito a configuração de VMs somente para experimentos com SDN. Ou seja, outros experimentos poderiam ser planejados como BigData com Hadoop, ferramentas de orquestração mais intensas como o HEAT do OpenStack, e virtualização com maior nível de abstração com controladores de SDN, deixando de existir a necessidade de FlowVisors para virtualização de SDN para múltiplos locatários. Além disso, a UFSCar tem desenvolvido drivers open-source para a DATACOM dentro do projeto Openstack Neutron e temos interesse em colocar em produção e testes nossos desenvolvimentos e possivelmente ampliar o escopo para controle fino de VLANs, já desenvolvido e também no futuro, controle fino de OpenFlow no equipamento. 2. Ambiente de testes O ambiente de testes foi utilizado totalmente em laboratório evitando, portanto, a inativação total da ilha como previsto no projeto original. Sendo a ilha UFSCar uma ilha de importância na infraestrutura do Fibre, foi desenvolvido um layout semelhante ao que seria usado (em menor escala) em laboratório. Todo o acesso externo ao ambiente foi controlado via VPN sem a necessidade de firewall para redirecionamento de portas com equipamento Mikrotik RB951G- 2HnD. O equipamento por si só tem a funcionalidade de roteamento de dados, VLAN além de servidor VPN com login e ou certificado nativo, excluindo necessidade de uma VM para esse controle eliminando também o redirecionamento de portas que pode aumentar de forma exponencial o número de ataques e DDOS. O hardware do ambiente de testes inclui: 2x switch datacom DM 4001 (sendo um com o funcionamento OpenFlow ativado) 2x Dell R302 Xeon E5 1x PC genérico Core i5, 8GB, 1 TB Como segue o layout : 2

3 Houve um atraso inesperado e gradativo na topologia final proposta como segue a figura 2: Esse atraso se deve a documentação da figura 1, onde as versões disponíveis para trabalho do plugin direto do OpenVirtex. A Figura 2 demonstra que o plugin desenvolvido no Havana foi desenvolvido para uma versão bem mais antiga da que a atual em desenvolvimento. O suporte de apenas 9 meses para o Havana (onde o plugin tem seu tutorial e funcionamento apontados como totalmente integrados) já são uma dificuldade. 3

4 A figura 3 demonstra o layout a ser entregue como resultado final e já teria sido alcançado se não fossem os percalços pela falta de repositórios para versões como Havana. Toda documentação de desenvolvimento está preparada para replicar em larga escala em ambiente Fibre como na figura 3, como uma das premissas de entrega: Acertando os repositórios para o Havana e acertando o plugin para OpenVirtex, toda a documentação será utilizada para replicar na ilha UFSCar o layout acima, com: OpenStack Havana Keystone Glance Neutron OpenVirtex Horizon Nova Swift* *Se houver tempo suficiente. Para cada nó de virtualização, uma nova bridge onde trafegará os dados para a rede SDN tem de ser adicionados manualmente seguindo a configuração da imagem 4: 4

5 Sendo assim, o que basta no momento é acertar as configurações manuais necessárias exigidas para o funcionamento do OpenVirtex com uma rede SDN em conjunto com om plugin do Neutron. 3. Lições aprendidas A riqueza de documentação[9] do OpenStack e se status consolidado no mercado de cloud define a tecnologia como um ponto de partida fidedigno a qualquer projeto de longa data. Tendo praticamente uma nova versão por ano e uma gama enorme de desenvolvedores envolvidos no trabalho de manutenção e otimização da plataforma já se justifica por si só a importância de seu uso. Um ponto que vale a pena ser mencionado é a pró atividade da comunidade em canais abertos (irc, fóruns e etc) quando nos deparamos por um problema não conhecido. Existem diversos softwares de administração e automação de instalação do uma infraestrutura inteira baseada em OpenStack, o que torna ainda mais interessante caso existam problemas diversos em uma ilha, um reboot completo pode ser atingido em questão de horas, desde a configuração quanto a sua personalização. Construir o ambiente apesar de alguns problemas corriqueiros que ainda não foram corrigidos na documentação original, tem sua resposta rápida para o conserto em uma pesquisa simples em qualquer ferramenta de busca. A quantidade de livros elaborados para construção de um ambiente com layout personalizado e a modularidade de funcionamento interno aumenta de forma significativa o debug de algum problema qualquer. O comitê gestor tem a sensibilidade de separar a documentação para: usuários, administrador e desenvolvedores, o que facilita na busca de soluções rápidas, a construção de um ambiente ou administração por um operador que não tem ou necessita de um conhecimento profundo da arquitetura interna do OpenStack. 5

6 4. Conclusão e avaliação Qual a sua avaliação? Os resultados esperados foram alcançados? Considerando a vasta documentação já citada, a quantidade de investimento de empresas no desenvolvimento e otimização da plataforma, fica claro que é um, se não o mais correto a ser investido para uma testbed como o projeto Fibre pretende contemplar. Tomando como premissa que o Fibre tende a ser uma testbed para internet do futuro, apenas SDN não é um ponto a ser coberto, visto que IoT[1], NFV [2] (Network Function Virtualization) dentre outros projetos tem se destacado e ainda faltam uma infraestrutura controlada para melhor desenvolvimento. O OpenStack tem cada vez mais modularizado seus recursos para comtemplar esses novos paradigmas e já pretende em suas próximas versões adicionar camadas e módulos para trabalhar sem problemas com cada uma delas. Além desses pontos, distribuições como Ubuntu Server, Fedora Server e CentOS em seus novos releases já tem os repositórios e se não parte da infra pré-instalada. Recursos como Juju[5], Devstack, Packstack dentre outros facilitam utilizar a ampla gama de kits de desenvolvimento sem necessitar de um ambiente em produção para testes ou melhorias, o que facilitaria para uma equipe focada em determinados pontos de desenvolvimento do OpenStack entregar resultados otimizados em módulos específicos sem interromper o fluxo de desenvolvimento central. O Horizon (frontend para o usuário) desenvolvido em Django tem ampla documentação de customização[7], não sendo um problema, portanto apresentar o Fibre como logotipo e marketing da testbed desenvolvida. A proposta inicial era adicionar um plugin do OpenVirtex para trabalhar diretamente com o módulo do Neutron-server no computador Controller. Esse passo foi atingido com grande dificuldade de integração e não obteve êxito pelo abandono da atualização do plugin para as novas versões de OpenStack, sendo a versão estável disponível pela Onlab[10] apenas para o Havana (2013.2) sendo hoje a Liberty ( ) a mais atual. A diferença de tempo entre as versões torna difícil (se não quase impossível) um replicar um ambiente com Havana justamente pela falta de repositórios. O tempo extra entre conseguir um ambiente funcional com OpenStack (1 semana) e tentar os bugfixes para o funcionamento em uma nova versão estourou o tempo limite do projeto sem poder entregar a plataforma com total integração em SDN apesar de outras alternativas estarem sendo estudadas. A vantagem da utilização direta do plugin do OpenVirtex[10] é manter a virtualização de redes como já existe no Fibre com o Flowvisor[12] e sem a necessidade do Onos[11] como demais projetos. Com algumas modificações pela equipe de desenvolvimento seria possível atingir exatamente a mesma entrega que o Ofelia tem, com menor índice de complicação e maior desempenho e documentação, além de uma transparência única para o usuário. Valeria apena a adoção da tecnologia prospectada no testbed FIBRE? Vejo que o próximo passo do Fibre como testbed em internet para o futuro, é criar sua própria estrutura, aproveitando de toda modularidade já bem documentada do OpenStack, as alterações seriam mais pontuais, os erros mais fáceis de serem solucionados e a testbed em si uma estrutura com maior facilidade de gerenciamento e monitoração. Todos os recursos que o Fibre possui hoje, o OpenStack oferece como demonstra a tabela 1: 6

7 Tabela 1: OpenStack OFELIA Horizon Expedient Nova OXA Neutron + OpenVirtex OptIn Neutron + OpenVirtex Flowvisor Keystone LDAP Ceilometer ZenOS É importante ressaltar, também que para o OMF existe o recurso de Barebone que pode ser integrado à solução e ao frontend. A curva de aprendizagem pela facilidade oferecida pelo Horizon e que pode ser visualizada no vídeo da referência X, demonstra o quanto o OpenStack seria uma boa (se não a melhor) alternativa para uma renovação total do Fibre. Outro ponto que vale a pena ressaltar, é que devido ao desenvolvimento do Ofelia como um todo, sendo ele um projeto abandonado, a atualização de softwares e segurança tem se tornado um risco para um ambiente que tem uma ligação direta em Layer 2 com diversas universidades. Além do mais, hoje estamos presos em virtualização via Xen, recurso que pode ser substituído por Hyper-V ESXi LXC QEMU KVM, até mesmo aproveitando máquinas com poder de processamento menor, tendo como ponto negativo um ambiente mais heterogêneo mas como ponto positivo, um suporte para uma demanda alta. Entendendo como internet do futuro a pesquisa de BigData (Sahaara), o OpenStack também pode fomentar esses pesquisadores além de servir como estrutura para demais projetos que não contemplem somente SDN e Wireless, mas NFV, IoT, Docker [4] (referência em diversos novos projetos) dentre outros. Além de que, seria um projeto referência em questão de testbed que, como já comentado com ferramentas de automatização, poderia ser replicado por qualquer universidade que venha a querer ter ou fazer parte da estrutura ou do Fibre. Qual seria o esforço para implantação da tecnologia prospectada em todo o testbed? A prioridade seria a atualização do plugin OpenVirtex[10] para o Neutron, tornando elegível para novas versões de OpenStack. Demais modificações já foram estudadas pelos outros projetos deste mesmo fluxo de tentativas, como apresentar uma topologia completa e escolher qual topologia será apresentada ao controlador. Acredito que com a junção dos conhecimentos adquiridos voltado ainda para a atualização do Ofelia, todos poderiam ser reaproveitados para o OpenStack, inclusive de seu frontend[7]. A facilidade é alta visto que existem diversos kits de desenvolvimento[6] e grande parte da atual equipe de desenvolvimento já tem contato e facilidade com a linguagem Python, utilizada em larga escala. Desde o desenvolvimento de um layout único para todas as ilhas, um gasto de tempo em desenvolver uma automação de instalação via Puppet ou Fuel podem trazer uma ilha em funcionamento em questão de horas. Um detalhe importante de ser mencionado é a questão de federação não somente entre ilhas mas com demais projetos. Atualmente há vários grupos (ou aggregates) que estão utilizando SFA para federação, como 7

8 PlanetLab PlanetLab Europe (PLE) PlanetLab Japan (PLJ) VINI GENI O PlanetLab fornece uma wiki com tutorial de como realizar a instalação e configuração do SFA Há informações a respeito de configurar o SFA no flavour os para OpenStack. Atualmente o driver OpenStack tem suporte às distribuições Essex e Folsom. Algumas pesquisas estão sendo desenvolvidas para manter duas opções de experimentação federada: 1. Controladores em comunicação horizontal. 2. Controladores em comunicação hierárquica. Ambos ainda em testes devido o grande tempo demandado em debug e bugfix na tentativa do plugin OpenVirtex funcionar com uma versão mais atual do OpenStack. 5. Referências Bibliográficas [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] 8