Instituto Metrópole Digital
SmartMetropolis
– Plataforma e Aplicações para Cidades Inteligentes
WP4 – Infraestrutura
Relatório de Atividades do Segundo Trimestre
Natal-RN, Brasil Julho/2016
Docentes
Prof. Dr. Carlos Eduardo da Silva (Coordenador) – IMD/UFRN Prof. MSc. Wellington Silva de Souza (CTC) - IMD/UFRN Prof. MSc. Aluizio Ferreira da Rocha Neto - IMD/UFRN Prof. Dr. Ivanovitch Medeiros Dantas da Silva - IMD/UFRN
Discentes
Luana Wandecy Pereira Silva Rafael Pereira Clemente Rafael Varela
Roberia Silva da Penha Lourenço Thais Alves de Freitas
Pesquisadores vinculados
Thomas Filipe da Silva Diniz - Anolis TI Hiago Miguel da Silva Rodrigues - Anolis TI
1 Introdução 6
2 Desenvolvimento, implantação e operação de Infraestrutura Computacional 6
3 Estudo de Ferramentas de Operação da Plataforma FIWARE 8
3.1 Ferramenta de Implantação da Plataforma . . . 9
3.2 Ferramentas de Operação de Plataforma . . . 11
3.3 Ferramenta de Análise da Plataforma-OPS-Health . . . 12
3.4 Ferramentas de Suporte - OPS-Toolkit . . . 12
3.5 Experimentos com as Ferramentas . . . 13
3.5.1 Recursos Disponíveis e Metodologia . . . 14
3.5.2 Experimento em Ambiente Virtualizado . . . 15
3.5.3 Experimento com nó físico . . . 18
3.6 Discussão . . . 21
4 Projeto de Implantação de Instância FIWARE de Produção 22 4.1 Diagnóstico DataCenter IMD e análise baseada nos requisitos FIWARE . . . 23
4.2 Projeto de Implantação . . . 24 4.2.1 Recursos Disponíveis . . . 24 4.2.2 Ambiente Proposto . . . 24 4.2.3 Planejamento de Rede . . . 25 4.3 Discussão . . . 26 5 Considerações Finais 27
1 Arquitetura da ferramenta Fuel. Fonte: https://wiki.openstack.org/wiki/
Fuel . . . 10
2 Arquitetura em ambiente virtualizado utilizando um servidor de teste. . . 15
3 Arquitetura de rede projetada para o ambiente virtualizado. . . 16
4 Arquitetura utilizada no experimento com KVM. . . 19
5 Arquitetura de rede utilizada no experimento com KVM. . . 21
1 Descrição da infraestrutura disponível para os experimentos. . . 14 2 Descrição da infraestrutura disponível para o ambiente de produção. . . 24 3 Ambiente de produção proposto. . . 25
1 Introdução
O projeto Smart Metropolis, conduzido pelo Instituto Metrópole Digital (IMD) da Universidade Federal do Rio Grande do Norte (UFRN), tem como objetivo o desenvolvimento de soluções de tecnologia da informação e comunicação para Cidades Inteligentes e Humanas.
Para facilitar o gerenciamento e evolução de suas atividades, o projeto foi dividido em seis Pacotes de Trabalho (Work Packages - WP) temáticos, liderados cada por um coordenador. Cada WP possui um conjunto de objetivos a serem alcançados ao longo dos cinco anos de execução do projeto. Este relatório está inserido no contexto do WP 4 - Infraestrutura Computacional, que no contexto do primeiro ano de execução do projeto Smart Metropolis, tem dois objetivos principais:
• Desenvolvimento, implantação e operação de infraestrutura computacional
Este objetivo envolve aspectos relacionados a formação de mão de obra capacitada para operar a infraestrutura computacional do projeto, assim como todos os aspectos relacionados à implantação de uma instância da plataforma FIWARE a nível de produção no ambiente computacional do IMD. A equipe atuante nesta tarefa é formada por: Prof. Dr. Carlos Eduardo da Silva (Coordenador da tarefa), Thomas Filipe da Silva Diniz (Anolis TI), Hiago Miguel (Anolis TI), e Rafael Varela (Bolsista Graduação) que substituiu o bolsista Antonio Alcir de Freitas Junior.
• Desenvolvimento de Smart Hot-Spot autonômico de acesso à Internet
Este objetivo desenvolve um hot-spot autonômico de acesso à Internet, com capacidade ao forne-cimento de conectividade a pessoas e dispositivos cyber-físicos no ambiente urbano. O hot-spot deverá possuir recursos de auto-suficiência energética e auto-adaptabilidade às condições de co-nectividade do ambiente.
A equipe atuante nesta tarefa é formada por: Prof. MSc. Aluizio Ferreira da Rocha Neto (Coorde-nador da tarefa), Prof. Dr. Ivanovitch Medeiros Dantas da Silva, Prof. MSc. Wellington Silva de Souza, Luana Wandecy Pereira Silva (Bolsista Mestrado), Thaís Alves de Freitas (Bolsista Gradu-ação), e Rafael Pereira Clemente (Bolsista Graduação).
Este documento apresenta o relato destas atividades para o segundo trimestre de execução do pro-jeto, dividido em duas partes. As atividades relacionadas à atividade de Desenvolvimento, implantação e operação de Infraestrutura Computacional são detalhadas em seguida, enquanto que as atividades relacio-nadas a atividade Desenvolvimento de Smart Hot-Spot autonômico de acesso à Internet são apresentadas em documento anexo.
2 Desenvolvimento, implantação e operação de Infraestrutura
Computa-cional
De acordo com o cronograma de execução do projeto, foram definidas um conjunto de atividades macro para o primeiro ano de execução do projeto. Estas atividades foram divididas em intervalos trimestrais, onde um determinado entregável deverá ser produzido.
Para o segundo trimestre de execução do projeto, foram inicialmente elencadas as seguintes atividades: 1. Estudo da plataforma OpenStack: Uma vez que a infraestrutura de suporte a computação em nuvem da plataforma FIWARE é baseada na plataforma Openstack, esta atividade envolve o estudo
e experimentação com os diversos componentes da plataforma de nuvem OpenStack em ambiente virtualizado, incluindo ferramentas de operação.
2. Estudo da plataforma FIWARE (ferramentas de operação): Esta atividade tem como foco o estudo e experimentação com as ferramentas de operação da plataforma FIWARE em ambiente virtualizado.
3. Projeto e implantação de instância FIWARE de treinamento: Esta atividade consiste no dese-nho do projeto, e implantação, da instância FIWARE de treinamento. Esta instância será implan-tada em um conjunto de servidores localizados no Datacenter do IMD, e que estão alocados para o projeto.
4. Estudo da plataforma FIWARE (mecanismos de segurança): Esta atividade visa um aprofun-damento dos estudos acerca dos mecanismos de segurança da plataforma FIWARE, envolvendo a experimentação com esses componentes de modo a demonstrar seu funcionamento. Esta atividade não estava inicialmente prevista para o primeiro ano de execução do projeto, e foi incluída ao final do primeiro trimestre, como apoio às atividades do WP-Middleware.
5. Projeto e planejamento de implantação de instância FIWARE de produção: Esta atividade tem como objetivo a definição do projeto de implantação da instância FIWARE de produção no ambiente computacional do IMD.
No início do segundo trimestre de execução do projeto foram realizadas algumas reuniões envolvendo a coordenação do projeto, membros de outros WPs, a equipe de TI do IMD, e a equipe da Anolis TI (empresa incubada que vem colaborando com o projeto) de maneira a coordenar as atividades a serem realizadas. Baseado nessas reuniões, algumas modificações foram necessárias no planejamento das ati-vidades para o segundo trimestre.
Uma das modificações diz respeito a tarefa Estudo da plataforma OpenStack. Identificamos uma sobre-posição referente a esta tarefa com um dos tópicos de estudo do WP-Middleware, de forma que a mesma foi desconsiderada pelo Infraestrutura. O motivo para tal alteração é que o foco do WP-Infraestrutura está mais relacionado a aspectos de implantação e operação de uma instância OpenS-tack/FIWARE de produção, enquanto que tal estudo apresentava uma visão de cliente da plataforma. Além disso, os estudos com as ferramentas de operação foram incorporados a tarefa Estudo da plata-forma FIWARE (ferramentas de operação).
Outra modificação diz respeito à tarefa Projeto e implantação de instância FIWARE de treina-mento. Durante o planejamento das atividades para o segundo trimestre, percebemos que esta instância seria implantada diversas vezes com configurações e topologias diferentes, de forma que não fazia mais sentido uma tarefa exclusiva para tal. Desse modo, a instância de treinamento, mais especificamente os recursos alocados para essa instância, foi incorporada a tarefa Estudo da plataforma FIWARE (ferra-mentas de operação), sendo utilizado para a realização de diversos experimentos.
A atividade Estudo da plataforma FIWARE (mecanismos de segurança) visa atender a uma de-manda do WP-Middleware, e portanto, seus resultados foram incluídos no relatório apresentado pelo WP-Middleware. É importante mencionar que esta mudança resultou na realocação da bolsista Roberia Silva da Penha Lourenço de atividades diretamente relacionadas ao WP-Infraestrutura para atividades do WP-Middleware, reduzindo assim a força de trabalho disponível para os aspectos de infraestrutura.
Desse modo, e para simplificar a coordenação das atividades realizadas, os esforços do WP-Infraestrutura ao longo do segundo trimestre do projeto foram agrupados em duas tarefas, que serão sumarizadas na sequência (e estão detalhadas neste relatório):
1. Estudo da plataforma FIWARE (ferramentas de operação): Esta tarefa envolveu o estudo das ferramentas indicadas/fornecidas pela plataforma FIWARE para a implantação, operação e manu-tenção de uma instância FIWARE (que corresponde a uma instância de uma nuvem OpenStack). Tal estudo explorou o ambiente reservado para a instância FIWARE de treinamento.
2. Projeto e planejamento de implantação de instância FIWARE de produção: O objetivo desta tarefa é de elaborar um projeto de implantação básico para a instância FIWARE de produção no ambiente computacional do IMD. Ela envolveu diversas interações com as equipes de TI do IMD e da Superintendência de Informática (SINFO) da UFRN.
3 Estudo de Ferramentas de Operação da Plataforma FIWARE
A plataforma FIWARE é formada por um conjunto de capítulos técnicos, que agrupam seus componentes (Generic Enablers - GE) em torno de tópicos em comum, tais como Computação em Nuvem, Gerenci-amento de Contexto, e Segurança. Cada GE apresenta uma especificação aberta, normalmente com um ou mais implementações concretas, que podem ser usadas por desenvolvedores.
Além desses capítulo técnicos, o FIWARE também apresenta um capítulo, denominado FIWARE OPS Tools[1], responsável pelo desenvolvimento de um conjunto de ferramentas que suportam as operações de implantação, monitoramento e manutenção em nós FIWARE Lab. De acordo com sua documentação, os principais objetivos deste capítulo são:
1. Permitir a configuração da infraestrutura partindo da instalação nos equipamentos de hardware (servidores) até sua inclusão no FIWARE Lab (ou configurada de forma independente em uma instância FIWARE isolada);
2. Oferecer serviços para as atividades operacionais da infraestruturas, incluindo: manutenção, atua-lização, estado atual de recursos e serviços de health-checking;
3. Contribuição para a comunidade OpenStack em termos de novas funcionalidades relacionadas com a implantação e operação de infraestruturas de nuvem.
De modo a atingir a esses objetivos, o capítulo técnico foi dividido em quatro tarefas macro, listadas a seguir:
• Ferramenta de Implantação de Plataforma (OPS-Deploy): tarefa dedicada às ferramentas de implantação e configuração da infraestrutura;
• Ferramentas de Operação de Plataforma (OPS-Dash): tarefa dedicada às ferramentas operaci-onais e de front-end de plataforma;
• Ferramenta de Análise da Plataforma (OPS-Health): tarefa dedicada às ferramentas de moni-toramento e análise de plataforma;
• Ferramentas de Suporte (OPS-Toolkit): tarefa dedicada às ferramentas de suporte e back-end. Foi feito um estudo preliminar sobre cada um desses grupos de modo a identificar as ferramentas que melhor se adequam ao ambiente computacional disponível considerando o expertise da equipe de implantação.
Baseado neste estudo, um conjunto de ferramentas foram elencadas para a realização de experimen-tos utilizando os recursos disponíveis para a instância FIWARE de treinamento. Estes experimenexperimen-tos se concentraram nas Ferramenta de Implantação de Plataforma (OPS-Deploy). Desse modo, a ativi-dade Projeto e implantação de instância FIWARE de treinamento foi incorporada à tarefa Estudo da plataforma FIWARE (ferramentas de operação), e consistiu na experimentação realizada com as ferramentas de operação, onde diversas instâncias FIWARE/OpenStack foram implantadas de modo a permitir à equipe uma experiência com as ferramentas de operação consideradas.
Na sequência, apresentamos as ferramentas disponíveis para cada grupo de tarefas relacionado a ope-ração, seguida de uma descrição dos experimentos realizados com a Ferramenta de Implantação de Plataforma (OPS-Deploy). Concluímos essa seção com uma breve descrição das próximas atividades a serem realizadas.
3.1 Ferramenta de Implantação da Plataforma
De acordo com a documentação para a implantação de nós FIWARE [2], existem diversas opções para a implantação de uma instância FIWARE:
1. Configuração manual: Consiste em seguir as instruções de instalação de uma nuvem OpenStack de acordo com sua documentação oficial.
2. Ferramenta de implantação Fuel: Consiste em uma ferramenta de código livre para a implantação de nuvens OpenStack.
3. Ferramenta de implantação OPS-Deploy: Consiste em um conjunto de plugins Fuel, junto com algumas outras alterações, para a implantação de uma instância da plataforma FIWARE de acordo com sua arquitetura de referência.
O critério de escolha acerca de qual opção utilizar depende principalmente do nível de customização desejada para os nós que comporão a infraestrutura de nuvem. Embora o OPS-Deploy possua um con-junto de plugins que permitam adicionar outras GEs a uma instância, as configurações apresentadas pela ferramenta pode não atender aos requisitos desejados, ou ser apropriada para os recursos disponíveis.
Desse modo, e uma vez que a equipe da Anolis TI já possui ampla experiência na implantação, ope-ração, manutenção e desenvolvimento de nuvens OpenStack baseado em sua documentação oficial, foi decidido explorar as ferramentas Fuel e OPS-Deploy. Foi dada maior ênfase a ferramenta Fuel, uma vez que o OPS-Deploy é um conjunto de plugins que podem ser adicionados a uma instalação Fuel.
O Fuel [3] é uma ferramenta de código aberto para a implantação e gerenciamento de nuvens OpenS-tack. O Fuel facilita o processo de implantação, teste e manutenção de vários ambientes OpenStack em larga escala. Dentre suas principais características, podemos citar o suporte a descoberta e configuração de novos hardware, o gerenciamento a diferentes nuvens OpenStack com suporte a configurações com e sem alta-disponibilidade, testes pre- e post- implantação, e uma interface Web para a visualização do ambiente e de logs em tempo real.
O Fuel é composto por vários componentes independentes. Alguns desses componentes são específicos do Fuel, enquanto outros são serviços de terceiros(Cobbler, Puppet, Mcollective, Astute e Nailgun). Sua arquitetura é mostrada na Figura 1.
O usuário consegue interagir com o Fuel utilizando uma interface Web, ou linha de comando (Web UI/CLI). Keystone representa o mecanismo de controle de acesso da plataforma OpenStack, onde os usuários da ferramenta são cadastrados. O componente principal do Fuel é o Nailgun, responsável pelo
Figura 1: Arquitetura da ferramenta Fuel. Fonte: https://wiki.openstack.org/wiki/Fuel
gerenciamento de todas as configurações do ambiente, incluindo volumes de disco, configuração de redes, entre outros dados relevantes. Nailgun armazena seus dados em uma base de dados SQL (SQL DB), e utiliza o serviço AMQP para interagir com o Astute. Este componente é responsável pela composição de agentes capazes de executar as ações e configurações solicitadas pelo Nailgun. Astute utiliza o Cobbler para a realização de provisionamento, sendo responsável por controlar os serviços de DHCP e TFTP da rede, afim de inicializar a gestão dos nós, iniciando e instalando o sistema operacional nos nós, com todas as definições que foram configuradas. Um conjunto de script (MCollective) são inicializados em todos os nós, onde estão sempre recebendo mensagens e executando ações do agente com esses dados recebidos. Por fim, o Puppet (Como parte dos agentes do MCollective) é responsável por efetivamente implantar o ambiente. Com ele podemos criar agentes MCollective para gerenciar outras estruturas de gerenciamento de configurações dos nós. O OSTF (OpenStack Testing Framework é um componente adicional que pode ser utilizado para a realização de testes após a implantação.
Estes componentes são agrupados em dois tipos de nós Fuel:
• Fuel Master node: o nó Fuel Master é um servidor com a aplicação Fuel instalada para implantar e gerenciar ambientes OpenStack. Ele é responsável pela configuração inicial dos nós que com-porão a infraestrutura OpenStack, realizando o provisionamento, e inicialização via PXE, além da atribuição de endereços IP para os Fuel Slave nodes.
• Fuel Slave node: consiste em um servidor que será provisionado pelo Fuel Master node. Este servidor assumirá um dos papéis de uma infraestrutura OpenStack.
Desse modo, a implantação de um ambiente baseado em Fuel exige a preparação do ambiente em termos de diferentes redes isoladas uma das outras, e a instalação de um nó Fuel Master. Uma vez que o Fuel Master esteja em funcionamento, servidores que serão utilizados como infraestrutura da nuvem OpenStack podem ser adicionados à mesma rede do Fuel Master, tornando-se nós Fuel Slave. Esses nós são automaticamente detectados pelo Fuel Master, e podem então ser configurados por meio de sua interface de acesso.
O Fuel suporta também a extensão de suas funcionalidades através de um conjunto de plugins. Existe uma gama de plugins disponíveis, incluindo plugin relacionados a rede (possibilitando a provisão de
firewall como serviço), monitoramento (permitindo a integração com outras ferramentas de monitora-mento como o Zabbix), armazenamonitora-mento (suportanto o uso de diferentes soluções de backend) e proces-samento (permitindo o uso de diveros hypervisors).
O OPS-Deploy é uma customização da ferramenta Fuel, incluindo modificações na interface de usuário Web para sua adaptação ao estilo similar ao utilizado pela FIWARE, e um conjunto de plugins específicos para a instalação de GEs do FIWARE. A versão atual do OPS-Deploy (4.0) é baseada na versão 7.0 do Fuel, suportanto a instalação da release Kilo (2015.1.0-7.0) do OpenStack em um sistema operacional Ubuntu 14.04. De acordo com seu repositório oficial1, esta versão recebeu sua última atualização em 26 de Fevereiro de 2016.
3.2 Ferramentas de Operação de Plataforma
Conforme mencionado anteriormente, as ferramentas de operação da plataforma FIWARE (OPS-Dash) são focadas em front-end que podem ser utilizados para se operar uma instância FIWARE que já se encontra implantada e em funcionamento.
São disponibilizadas três ferramentas: O FIDASH, o SLA Manager and Dashboard, e o Mainte-nance Calendar.
O FIDASH [4] é um dashboard de administração e gestão para uma instância FIWARE. Ele oferece um painel de controle para executar operações de infraestrutura, monitoramento e comunicação do FIWARE. Ele é uma versão adptada do WireCloud2, e como tal, possui um mashup personalizável, permitindo assim, o usuário definir de maneira simplificada a funcionalidade e comportamento do painel FIDASH. Esse painel é formado por vários elementos (widgets), que o usuário pode escolher, descartar, configurar o layout, alem de modificar o seu comportamento.
Para dar apoio a algumas ações, os Widgets possuem APIs baseadas nos serviços oferecidos pelo OpenStack, porém alguns serviços são acessados diretamente. A autenticação é coordenada pela plata-forma WireCloud, em conjunto com o GE Identity Management (IDM), componente responsável pela gestão de identidades e acesso na plataforma FIWARE. Os Widgets estão interconectados, para desem-penhar certas funções de alto nível, e para fornecer informações baseadas nas ações feitas por outros componentes. Essa conexão é feita por um mecanismo chamado wiring. Os usuários podem conec-tar/desconectar qualquer wiring, modificando o comportamento do painel.
O FIDASH traz um conjunto pré-definido de widgets configurados em um dashboard pronto para uso, que pode ser livremente modificado. Além dos serviços já oferecidos pelo dashboard oficial do OpenStack, o FIDASH traz um conjunto de widgets com funcionalidades extras, algumas específicas para gerenciar GEs do FIWARE.
SLA Manager and Dashboard suporta serviços para gerenciamento de SLA (Service-Level Agre-ement) na plataforma FIWARE, oferecendo recursos de monitoramento da uma instância FIWARE in-tegrado ao FIDASH. O SLA Manager [5] é um serviço de back-end que implementa um sistema ge-renciador de ciclo de vida de SLA de acordo com a especificação WS-Agreement. Este componente permite o gerenciamento de todo o ciclo de vida de SLAs, desde a criação de templates, ate a detecção de violação. O SLA Manager é baseado em plugins, podendo ser adaptado e extendido para ser utilizado em diferentes plataformas. O SLA Dashboard [6], fornece uma interface de usuário Web, que permite o gerenciamento de todo o ciclo de vida de SLA, expondo as operações do SLA Manager (que atua como back-end). Com isso, o usuário pode estabelecer SLAs e registrar violações de SLA, podendo operar a
1https://github.com/SmartInfrastructures/fuel-main-dev/ 2
nível de host, máquina virtual ou serviço.
O Maintenance Calendar [7] é um front-end para uma funcionalidade do OPS-Toolkit que permite a definição dos períodos de manutenção para as diferentes regiões FIWARE Lab de uma forma organizada. Com isso, este componente visa simplificar a comunicação dos eventos para aqueles interessados, por exemplo usuário ou alguma ferramenta OPS-Health. Ele consegue separar os eventos entre as regiões, e apoia as definições dos pedidos de periodos sem manutenção para pessoas autorizadas, como por exem-plo desenvolvedores, ou o pessoal de marketing que necessitam fazer algum evento, e seria necessário a nuvem em execução sem ser interrompida em determinadas datas. A autorização é realizada em ambos, front-end e back-end, e somente usuários autorizados podem criar eventos, enquanto que cada usuário pode vê-los.
3.3 Ferramenta de Análise da Plataforma-OPS-Health
O OPS-Health é um conjunto de ferramentas de código aberto para OpenStack que ajuda os usuários a saber o status de qualquer instância FIWARE. Ele oferece ferramentas para três operações de análise: verificação de sanidade (Sanity Check Engine e Sanity Check Dashboard), página de status e informações gráficas (Infographics & Status Page) e monitoramento de federação (Federation Monitoring).
O Sanity Check Engine and Dashboard permite a realização de um grande número de testes de sanidade ao longo de cada instância FIWARE, permitindo identificar o estado atual de uma instância FIWARE. Esta ferramenta é dividida em um componente de back-end (Sanity Check Engine [8]) e um componente de front-end (Sanity Check Dashboard [9]). Além de oferecer um conjunto de casos de testes, e coordenar sua execução através de seu componente de back-end, a ferramente apresenta uma visualização gráfica dos resultados dessas execuções. A Sanity Check Dashboard mostra uma visão geral de todos os testes realizados e os status de cada instância FIWARE, mostrando registros detalhados para os teste que falharam. Esta ferramenta permite que os usuários e administradores saibam facilmente quais recursos de uma região estão funcionando bem ou com algum tipo de problema.
O Infographics & Status Page [10] é uma ferramenta que permite aos usuários consultar, de forma in-tuitiva, a capacidade da infraestrutura em relação a recursos disponibilizados por uma instância FIWARE, e para monitorar o estado geral do FIWARE Lab. É uma interface Web que obtém informações dos com-ponentes Federation Monitoring e Sanity Check Engine.
O Federation Monitoring [11] é um componente que fornece dados de monitoramento de uma ins-tância FIWARE Lab, permitindo o gerenciamento de falhas e de desempenho de aplicações server-side e de rede. Este componente é capaz de obter informações de diversas ferramentas de monitoramento, simplificando sua apresentação aos usuários finais. Ele é baseado no Ceilometer, projeto oficial de mo-nitoramento da plataforma OpenStack.
3.4 Ferramentas de Suporte - OPS-Toolkit
O OPS-Toolkit fornece um conjunto de ferramentas para extendes as ferramentas OpenStack ous adi-cionar novos componentes de middleware para implementar alguma funcionalidade necessária para a operações de uma instância FIWARE. A maioria das ferramentas apresentam APIs que podem ser utili-zadas para que operadores tenham uma interface de usuário através do FIDASH.
Dentre as ferramentas fornecidas temos: Flavor Synchronization tool, Maintenance Calendar tool (backend), Glance synchronization tool (GlanceSync), User management tool (Skuld), e Public keys ma-nagement tool (Aiakos).
O Flavor Synchronization tool [12] permite a publicação e sincronização de templates de configura-ção para máquinas virtuais, denominados como "flavors". Esta ferramenta foi pensada para ser utilizada em um ambiente federado, como o FI-LAB, onde diversos provedores de nós podem usar nomes diferen-tes para se referir à uma mesma configuração base de máquina virtual. A ferramenta permite a publicação de informações de “flavors” particulares, assim como a instalação de outros “flavors” públicos em sua própria infraestrutura, fornecendo operações básicas como criar, pesquisar, atualizar e excluir “flavor” nessas infraestruturas.
O Maintenance Calendar tool (backend) [13] permite que operadores de infraestrutura criem even-tos de manutenção para usuários e componentes FIWARE. Baseado no padrão CalDAV, ele permite que vários clientes acessem e compartilhem informações sobre eventos, suportando também a utilização de diversos servidores de calendário. A ferramenta permite a indicação de janelas de manutenção, quando a infraestrutura poderá estar indisponível, assim como de janelas de não-manutenção, que indica períodos no qual a instância deve estar online, suportando o envio de notificações para usuários.
O Glance synchronization tool (GlanceSync) [14] permite a sincronização de imagens de máquina virtual em uma nuvem OpenStack. Este componente simplifica a sincronização de imagens gerenciada pelo Glance, componente OpenStack que gerencia as imagens disponíveis para a criação de novas má-quinas virtuais. O software é configurável, e não possui qualquer requisito especial, além das bibliotecas OpenStack. Alem disso, ele pode ser utilizado em qualquer outro projeto ou como uma ferramenta gené-rica para sincronização de imagens.
A ferramenta User management tool (Skuld) [15] é o componente responsável pela liberação de recursos alocados a usuários temporários após a expiração de suas contas. O propósito é garantir que recursos alocados a usuários de testes possam ser disponibilizados a outros usuário ao fim do período de testes. A remoção de recursos segue um workflow pre-determinado de acordo com o tipo de recurso.
O Public keys management tool (Aiakos) [16] armazena chaves públicas correspondentes a cada nó do FIWARE Lab, para garantir o acesso de suporte às máquinas virtuais no FIWARE Lab. Isso se faz necessário pois toda máquina virtual instanciada é acessível através de chaves públicas, uma para cada usuário que acessa o sistema, permitindo assim um acompanhamento de quais usuários acessam quais máquinas virtuais.
3.5 Experimentos com as Ferramentas
Baseado em uma análise preliminar, e em discussões com a equipe de TI do IMD e com o membro do WP-Middleware Arthur Cassio, decidiu-se focar os experimentos nas ferramentas de implantação da plataforma. Outro motivo para esta decisão é o impacto que tais ferramentas trazem ao projeto de implantação da instância FIWARE de produção.
Como já visto na seção 3.1, decidiu-se realizar os experimentos utilizando o Fuel. Uma vez que a ferramenta OPS-Deploy é fortemente baseada no Fuel, tendo como diferença um conjunto de plugins e customização voltadas para a plataforma FIWARE, julgamos mais importante conhecer a ferramenta base, que permite a aplicação de plugins conforme a necessidade do ambiente a ser configurado. Desse modo, os plugins disponibilizados pelo OPS-Deploy podem ser facilmente aplicados ao Fuel, se assim julgar-se necessário.
Além disso, foram realizados alguns experimentos preliminares com a ferramenta OPS-Deploy por parte do membro da equipe do WP-Middleware Arthur Cassio no contexto de uma instância FIWARE para ser utilizada para desenvolvimento, e a mesma se mostrou problemática. O OPS-Deploy apresentou algumas dificuldades para sua instalação e implantação da plataforma de nuvem, e após implantada,
instâncias criadas não eram acessíveis. Como solução, as GEs utilizadas para desenvolvimento foram implantadas através de containers rodando em máquinas virtuais hospedadas no Datacenter do IMD. É importante mencionar que essas GEs estão totalmente isoladas umas das outras, sem integração entre elas ou aos serviços de nuvem do IMD. Este foi outro fator motivador para decidirmos explorar o Fuel em nossos experimentos.
Serão apresentados dois experimentos, onde em cada um uma instância completa da plataforam OpenS-tack foi instanciada usando-se a ferramenta Fuel.
O primeiro experimento seguiu as orientações da documentação oficial da plataforma FIWARE, que indica a versão 7.0 do Fuel, baseada no OpenStack Kilo, sendo que já estava disponível a versão 9.0, baseada no OpenStack Mitaka. Algo a se levar em conta é que o Fuel possui dois segmentos, isto é, o Fuel tem a sua versão community, que utiliza o OpenStack, e a versão que utiliza o Openstack Miran-tis. Aparentemente não há mudanças significativas entre ambos. Foi utilizado o segundo segmento na implementação, conforme orientações da documentação FIWARE.
A utilização da versão 7.0 do Fuel apresentou diversas dificuldades causadas por erros na utilização da ferramenta quando da implantação da nuvem OpenStack, e em seu funcionamento após implantada. Baseado nessa experiência, decidiu-se utilizar a versão mais atualizada do Fuel para os próximos ex-perimentos, adotando assim a versão 9.0 oficial da comunidade OpenStack (a última release estável do projeto OpenStack).
Antes de apresentar os experimentos realizados, descrevemos a infraestrutura disponível.
3.5.1 Recursos Disponíveis e Metodologia
Essa seção apresenta os recursos disponíveis para os experimentos que foram realizados, seguido de uma descrição dos passos necessários para se implantar uma nuvem OpenStack baseada na ferramenta Fuel. Esses recursos estavam alocados para a criação da instância FIWARE de treinamento, e não impactaram nos recursos disponibilizados pelo Datacenter do IMD para outras atividades do projeto.
Temos disponíveis um total de quatro servidores: um servidor Dell PowerEdge R730 e três servidores Dell PowerEdge 530. A configuração desses servidores é apresentada na Tabela 1. A forma em como esses servidores foram utilizados serão detalhadas em cada experimento.
Tabela 1: Descrição da infraestrutura disponível para os experimentos.
Servidor Dell PowerEdge R530 Dell PowerEdge R730
Processador Intel XeonR E5-2620R v3 2.4GHz 6 núcleos
Intel XeonR E5-2630R
v3 2.4 GHz 8 núcleos
Memória 16 GB 128 GB
Armazenamento 2 discos de 1 TB SATA 8 discos SAS de 600 GB
Rede 4 x NetXtreme BCM5720
Giga-bit Ethernet PCIe
4 x NetXtreme BCM5720 Giga-bit Ethernet PCIe
A utilização do Fuel para a implantação de uma nuvem OpenStack pode ser resumida em quatro passos:
1. Preparação do Ambiente: envolve a configuração de servidores e topologia de redes. O Fuel ne-cessita de cinco redes distintas para seu funcionamento. Uma vez que cada experimento usou uma configuração diferente, o detalhamento das configurações serão apresentadas em suas respectivas seções.
2. Instalação e configuração do servidor Fuel master: envolve a instalação de sistema operacional baseado em imagem ISO Fuel, contendo os diversos serviços necessários para seu funcionamentto, assim como uma interface de acesso Web.
3. Configuração do ambiente OpenStack via interface Web Fuel: uma vez instalado e operacional, o servidor Fuel master é capaz de detectar os servidores disponíveis no ambiente, que precisam então serem configurados em termos dos serviços OpenStack que cada uma vai executar.
4. Implantação e testes: o último passo consiste na implantação do ambiente, conduzida de forma automática pela ferramental Fuel, e na realização de um conjunto de testes para verificar a correta implantação do ambiente OpenStack.
3.5.2 Experimento em Ambiente Virtualizado
O primeiro experimento tinha como objetivo um entendimento básico da ferramenta Fuel, e foi realizado em um ambiente totalmente virtualizado.
Da Estrutura e Ambiente de Testes Os testes iniciais foram realizados em um servidor Dell PowerEdge R530, conforme descrito na tabela 1. Iniciamente foram virtualizados todos os recursos, com excessão do espaço em disco, onde foram virtualizados dois discos de 500GB. No ambiente expe-rimental foi utilizado o CentOS como sistema operacional e o QEMU3 como hypervisor. Via QEMU foi virtualizado todo o ambiente de testes, isto é, o Fuel 7 e as máquinas que compõem o ambiente OpenStack.
Figura 2: Arquitetura em ambiente virtualizado utilizando um servidor de teste.
A figura 2 retrata o ambiente virtualizado onde os testes foram feitos. Estas máquinas virtuais são gerenciadas pela equipe do projeto, e foram criadas com o objetivo de simular uma infraestrutura a ser
3
utilizada por uma nuvem OpenStack. Segue abaixo uma breve descrição das máquinas que compõem esse ambiente:
• Fuel Master. Responsável pelo deploy do ambiente OpenStack;
• Controller. Nó que executa a API dos componentes do OpenStack, além dos serviços de rede, imagem, scheduler e volume;
• Compute. Nó que executa o nova-compute e que gerencia as máquinas virtuais instanciadas; • Storage I / Storage II. Nós para Block storage e Object storage, sendo responsável por executar
o cinder-volume e de prover serviços de containers, accounts e objects, além gerenciar o banco de dados de tais serviços;
• Ceilometer. Responsável por executar o banco de dados NoSQL MongoDB, para armazenar as estatísticas e dados coletados do ambienteStack OpenStack.
É importante salientar que esse ambiente segue os requisitos definidos pela plataforma FIWARE, que define um conjunto mínimo de serviços que precisam ser oferecidos por uma nuvem OpenStack para que a mesma possa ser identificada como uma instância FIWARE.
Do Planejamento de Rede O Fuel depende da implantação de cinco redes distintas para o seu funcionamento. Deve-se levar em conta que a definição dessas cinco redes determinadas pelo Fuel serve para segregar o tráfego, evitando assim problemas relacionados à segurança e desempenho. As cinco redes criadas são apresentadas na Figura 3 e listadas em seguida:
Figura 3: Arquitetura de rede projetada para o ambiente virtualizado.
• Rede (Admin) PXE. Utilizada pelo nó Fuel Master para o provisionamento e orquestração do ambiente OpenStack;
• Rede Pública (Public). Permite que as máquinas virtualizadas do ambiente tenham acesso à in-ternet;
• Rede de Gerenciamento (Management). Contém o tráfego de requisições de banco de dados, de mensagens AMQP e serviços de alta disponibilidade, além do tráfego iSCSI entre os nós compute e storage;
• Rede Privada (Private). É utilizada para o tunelamento do tráfego de projetos OpenStack; • Rede de Armazenamento (Storage). Lida com o tráfego de replicação do Swift (serviço de
ar-mazenamento de objetos OpenStack).
Assim, como exigido pelo Fuel, essas cinco redes foram implantadas no ambiente. O switch virtual, retratado na figura, exemplifica o conceito de virtual switch utilizado pelo libvirt4. Basicamente, trata-se de um software definido em um host, que permite que uma ou mais máquinas virtuais se comuniquem através de uma mesma rede. Com exceção da rede pública, todas as demais redes foram criadas virtual-mente através do libvirt, em modo isolado. A rede pública, por sua vez, é utilizada no ambiente virtual, mas nada mais é do que uma bridge que utiliza uma interface física do servidor smart, dando acesso às maquinas à rede do IMD. Para um melhor entendimento, será descrito em seguida como as redes foram definidas em cada uma das máquinas:
• Os servidores smart-ctrl, smart-str, smart-comp e smart-db utilizam cinco interfaces de rede, cada uma para uma das cinco redes determinadas pelo Fuel. As bridges exibidas na figura 3, com exceção da br-ex, são todas provisionadas pelo Fuel.
• O servidor fuel-master utiliza apenas duas interfaces de rede, uma para a rede administrativa PXE e outra para a rede pública.
O uso de vlans (Virtual Local Area Network) nesse contexto é opcional. Isso se deve ao fato de que nesse ambiente utilizamos uma placa de rede dedicada para cada uma das redes, dispensando assim o uso de identificadores nos dados trafegados. Deve-se levar em consideração que a rede PXE não deve receber nenhuma tag (identificador de vlan), de modo a permitir a inicialização (boot) de servidores via rede.
Descrição do Ambiente OpenStack A figura 3 retrata as máquinas virtuais utilizadas no ambiente OpenStack provisionado pelo Fuel. Abaixo segue uma descrição do papel de cada uma delas:
• smart-ctrl. Desempenha o papel de controller, executando uma série de serviços para gerenciar a operação da nuvem, além de mecanismos de controle de acesso. Esse nó executa os seguin-tes serviços do OpenStack: scheduler, api, conductor, consoleauth, nova-novncproxy, cinder-api, cinder-scheduler, glance, neutron-server, neutron-l3-agent, neutron-dhcp-agent, neutron-metadata-neutron-dhcp-agent, heat-api, heat-engine, swift-proxy, ceilometer-api, ceilometer-collector, ceilometer-agent-central, ceilometer-agent-notification, keystone, e murano, além do horizon.
• smart-comp. Desempenha o papel de compute, utilizando como hypervisor o QEMU, já que esta máquina é virtualizada. Executa os seguintes serviços: nova-compute, e neutron-agent.
• smart-str. Desempenha o papel de Object Storage e Block Storage. Esse nó executa os seguintes serviços: swift-account-server, swift-container-server; swift-object-server, e cinder-volume. • smatr-db. Serve de back-end para o ceilometer, o serviço de monitoramento OpenStack, e portanto
roda um único serviço: mongodb.
Testes de Utilização da Nuvem Com o deploy do ambiente OpenStack finalizado, foram realiza-dos alguns testes para comprovar sua correta operação. O Fuel oferece um conjunto de testes (health checks) que permite verificar a funcionalidade da nuvem implantada. Estes testes oferecem informações de status dos componentes mais utilizados, como também das operações mais realizadas. Dessa forma, para testar o ambiente, foram executados os health checks, que comprovaram a corretude do mesmo. Além disso, foram criadas dez instâncias, isto é, máquinas virtuais, executando o Ubuntu 16.04, com 384 megabytes de memória RAM e 20 gigabytes de armazenamento e duas interfaces de rede, uma para o acesso à rede pública e outra para o acesso à uma rede privada. Também foi testado o acesso às ins-tâncias através do protocolo ssh, secure shell. Com isso, pode-se comprovar o correto funcionamento do ambiente OpenStack provisionado pelo Fuel.
Problemas encontrados O processo de instalação do Fuel Master ocorreu sem problemas, porém o mesmo não ocorreu com o deploy do ambiente, já que o Fuel apresentou um bug. Após o provisiona-mento dos servidores, ou seja, após a instalação do sistema operacional, o Astute, componente do Fuel, não detectava o reiniciamento das máquinas. Como consequência, o processo de deploy ficava aguar-dando esse reiniciamento até atingir um timeout, interropendo o deploy com erro. A solução adotada foi, após o sistema operacional ser instalado nas máquinas, reiniciá-las manualmente. Assim o deploy teve continuidade e foi finalizado com sucesso.
É importante levar em conta alguns pontos antes da realização de um deploy, tais pontos são cruciais para um deploy funcional, isto é, sem erros, de um ambiente. Esses pontos são:
• NTP: A lista de servidores NTP definida no processo de pós-instalação deve ser funcional, isto é, o Fuel Master deve ser capaz de sincronizar o horário com um dos servidores NTP;
• DNS: O Fuel Master deve ser capaz de resolver nomes para endereços válido na rede em que ele se encontra.
3.5.3 Experimento com nó físico
Baseado no aprendizado com o experimento em ambiente virtualizado, o segundo experimento condu-zido envolveu a utilização de um servidor físico como nó de compute, simulando assim um ambiente mais próximo da realidade.
Comparado com o experimento anterior, onde foi utilizado o QEMU, o hypervisor usado nesses ex-perimentos foi o KVM (Kernel-based Virtual Machine), de acordo com os requisitos estabelecidos pela plataforma FIWARE. Uma outra diferença foi a utilização da versão community do Fuel. Baseado nos problemas encontrados com o Fuel 7.0, foi optado por se utilizar a versão 9.0, sendo esta a última release estável do projeto.
Da Estrutura e Ambiente de Testes Nessa segunda etapa dos testes, foram utilizados dois ser-vidores Dell R530 com características semelhantes ao do primeiro experimento, apresentando duas pe-quenas diferenças no que diz respeito ao espaço de armazenamento. O primeiro servidor utilizava dois
discos de 500GB, enquanto que o segundo utilizava apenas um disco de 500GB. A Figura 4 apresenta a configuração utilizada pelos dois servidores. O servidor smart é responsável pela maioria do ambi-ente de testes, com exceção do nó compute, o qual é desempenhado pelo servidor smart-comp. Como mencionado anteriormente, foi utilizado o KVM como hypervisor.
Figura 4: Arquitetura utilizada no experimento com KVM. Segue abaixo uma breve descrição das máquinas que compõem esse ambiente:
• Servidor smart: contém diversas máquinas virtuais, gerenciada pela equipe do projeto, que servi-ram como infraestrutura de base para a implantação da nuvem OpenStack
– Fuel Master. Responsável pelo deploy do ambiente OpenStack;
– Controller. Nó que executa a API dos componentes do OpenStack, além dos serviços de rede, imagem, scheduler e volume;
– Storage I / Storage II. Nó Block storage e Object storage, sendo responsável por executar o cinder-volumee de prover serviços de containers, accounts e objects, além gerenciar o banco de dados de tais serviços;
– Ceilometer. Responsável por executar o banco de dados NoSQL MongoDB, para armazenar as estatísticas e dados coletados do ambienteStack OpenStack.
• Servidor smart-comp: Corresponde ao nó de compute, executando o nova-compute diretamente sobre o sistema operacional da máquina física. As máquinas virtuais que rodam nesse servidor são todas gerenciadas pela plataforma OpenStack.
Do Planejamento de Rede A adição de um servidor físico ao ambiente resultou em uma remo-delagem da topologia de rede adotada. Para que o nó smart, as demais máquinas virtualizadas, e o nó smart-comp se comunicassem propriamente, foi necessário criar as redes Fuel Admin PXE, Manage-ment, Private e Storage no switch do datacenter do IMD, cada uma delas com a sua vlan específica. O
uso de tags, isto é, de identificadores nas vlans, fez-se necessário para a identificação do tráfego de cada uma das redes utilizadas pelo Fuel, já que não se tinha placas de redes exclusivas para cada uma delas. Através da dashboard do Fuel, foram alocadas as cinco redes definidas por ele nas 4 placas de rede do nó smart-comp, adotando o seguinte arranjo:
• em1. Porta para a rede administrativa PXE, sem tag. Interface utilizada pela bridge br-ex;
• em2. Interface utilizada pelas bridges br-ex e br-mgmt, sendo utilizada, consequentemente, pelas seguintes redes:
– Public e Floating, sem tag; – Management com tag 1001.
• em3. Porta para a rede Private com tag 1002. Interface utilizada pela bridge br-mesh; • em4. Porta para a rede Storage com tag 1003. Interface utilizada pela bridge br-storage.
Já o servidor smart, utiliza as interfaces de rede de maneira diferente. A interface br-mps é uma bridgeutilizada pelas redes Management, Private e Storage, assim todo o tráfego proveniente dessas redes trafega por essa interface, possibilitando a comunicacão entre os nós do ambiente. O servidor smart adotou o seguinte arranjo:
• br-pxe. Bridge que utiliza a interface física em2 do servidor. Utilizada pela rede administrativa PXE;
• br-ex. Bridge que utiliza a interface física em1 do servidor. Utilizada pela rede Pública e Flutuante (Public e Floating);
• br-mps. Bridge que utiliza as interfaces físicas em3 e em4 do servidor. Utilizada pelas redes: – Gerenciamento (Management);
– Privada (Private);
– Armazenamento (Storage).
A Figura 5 exemplifica a arquitetura de rede adotada, levando em consideração tanto o ambiente virtualizado, isto é, o ambiente OpenStack, quanto o ambiente Físico, isto é, os servidores smart e smart-comp.
Descrição do Ambiente OpenStack O ambiente OpenStack provisionado pelo Fuel no experi-mento com o KVM é praticamente idêntico ao que foi retratado nos testes realizados com o QEMU, tendo como única diferença o hypervisor. Assim, a descrição dos serviços desempenhados por cada nó se repete.
• smart-ctrl. Desempenha o papel de controller, executando uma série de serviços para gerenciar a operação da nuvem, além de mecanismos de controle de acesso.
• smart-comp. Desempenha o papel de compute, utilizando como hypervisor o KVM. • smart-str. Desempenha o papel de Object Storage e Block Storage.
Figura 5: Arquitetura de rede utilizada no experimento com KVM.
Testes de Utilização da Nuvem O ambiente OpenStack provisionado foi testado através dos heatlh checks, já citados no experimento em ambiente virtualizado. Também foram criados o máximo de ins-tâncias, isto é, máquinas virtuais que o ambiente pôde suportar. Assim, foram instanciadas 38 máquinas executando o Ubuntu 16.04, com 384 megabytes de memória RAM e 10 gigabytes de armazenamento. Foram realizados também testes de acesso remoto às máquinas virtuais. Com isso, teve-se um ambi-ente experimental completamambi-ente funcional, contemplando desde o uso de ferramentas de implantação à utilização da nuvem para a criação de máquinas virtuais.
Problemas encontrados A versão 9.0 do Fuel apresentou um bug durante o processo de deploy. O serviço rabbitmq-server não era iniciado devido a um problema de resolução de nome, por conse-guinte o deploy atingia um timeout sendo interrompido com erro. A solução adotada foi a alteração do arquivo /etc/hosts do nó controller, relacionando o nome do servidor com o seu endereço IP de loopback. Realizando essa alteração o deploy teve continuidade e foi terminado com sucesso. Além disso, foram en-contrados alguns erros de configuração no switch do datacenter do IMD. Estes erros foram rapidamente solucionados em interação com a equipe de TI do IMD.
3.6 Discussão
Os experimentos realizados permitiram à equipe uma familiaridade com a ferramenta Fuel, e a dispo-nibilização de recursos físicos para o mesmo pode ser considerado um dos pontos chaves. Sem esses recursos, não teria sido possível simular um ambiente próximo da realidade.
O problema encontrado no primeiro experimento ocupou um tempo considerável da equipe, uma vez que o mesmo não estava documentado, e buscas em fórums da comunidade OpenStack se mostraram infrutíferas. Durante o segundo experimento foi detectado alguns problemas de configuração no Data-center do IMD, que foram rapidamente resolvidos com o conjunto de instruções elaborados pela equipe para tal.
Um terceiro experimento foi iniciado, envolvendo tanto a manipulação de plugins da ferramenta Fuel, e testes com ambiente baseado em container (através do plugin nova-docker do OpenStack). Os primeiros testes confirmaram a possibilidade de se adicionar plugins Fuel em um ambiente de produção, que não tinha sido conseguido com a versão 7.0 do Fuel.
Baseado nisso, iniciou-se os testes com um plugin do Fuel para suportar a implantação do nova-docker em uma instância de nuvem OpenStack, de forma a suportar o gerenciamento de containers através da plataforma OpenStack. Para esses experimentos, um terceiro servidor físico foi adicionado à infraestrutura base da nuvem, exigindo algumas alterações nas redes (vlans) definidas.
O plugin do nova-docker, disponibilizado pela comunidade, se encontrava incompatível com a versão 9 do Fuel devido às mudanças trazidas pela mesma. Assim, para que o plugin pudesse ser utilizado, foi necessário algumas alterações em seu código. Dessa forma, foi realizado um fork do repositório do plugin no GitHub, como também as alterações necessárias e a realização de um pull request. Com isso, o plugin do nova-docker se apresentou compatível. As alterações consistiram na mudança da especificação das releasesdo OpenStack suportadas, da versão do pacote do plugin e do Fuel, da restruturação de algumas arquivos, e de algumas correções na documentação. O fork do plugin se encontra no endereço https: //github.com/anolisti/fuel-plugin-novadocker/tree/stable/mitaka. Embora o plugin tenha sido implantado com sucesso, esses testes não puderam ser concluídos, faltando a reali-zação da implantação de um nó OpenStack baseado no nova-docker, e a criação de máquinas virtuais e containers sobre esse ambiente.
É importante mencionar que as modificações realizadas pela equipe ao plugin Fuel foram submetidas para a comunidade OpenStack, e se encontram atualmente em processo de revisão.
Como recomendações de próximos passos, sugerimos as seguintes tarefas:
• Finalização dos testes com plugin nova-docker e seu uso para testes com ambientes de gerencia-mento de containers.
• Estudos e experimentos com as outras ferramentas disponibilizadas pelo capítulo OPS Tool: OPS-Dash, OPS-Health e OPS-Toolkit.
4 Projeto de Implantação de Instância FIWARE de Produção
A implantação de uma instância FIWARE a nível de produção é uma tarefa árdua, com um elevado grau de complexidade e custo considerável. Isso se dá devido aos requisitos para a operação de uma nuvem OpenStack, que serve de base para os serviços oferecidos pelo FIWARE.
A definição do projeto de implantação da instância FIWARE de produção seguiu as recomendações no documento de análise de requisitos produzido no primeiro trimestre de execução do projeto. Dessa forma, e seguindo a recomendação daquele relatório, foi realizado um levantamento acerca da capacidade atual do ambiente computacional disponível no Datacenter do IMD. Com base nisso, reuniões envolvendo a equipe do projeto e a equipe de TI do IMD foram realizadas de forma a analisar os requisitos do FIWARE em relação aos recursos disponíveis no Datacenter do IMD, buscando maximizar a integração entre a infraestrutura já existente com a infraestrutura a ser alocada para a instância FIWARE, além de considerar as características da infraestrutura de rede da UFRN.
Na sequência descrevemos o resultado desta análise, seguida por uma proposta de projeto de implan-tação de uma instância de produção baseada nos recursos disponíveis, com previsão de crescimento com a adição de novos recursos.
4.1 Diagnóstico DataCenter IMD e análise baseada nos requisitos FIWARE
Inicialmente foi feito um levantamento acerca de todos os recursos atualmente em funcionamento no DataCenter do IMD. Este diagnóstico foi feito pela equipe de TI do IMD, mais especificamente pelo Prof. Itamir de Morais Barroca Filho e o Analista de suporte André Campos Bezerra. O detalhamento deste levantamento não será apresentado neste relatório, onde faremos um sumário dos recursos.
O Datacenter do IMD conta, no momento da escrita deste relatório, com equipamentos de armazena-mento de alto-desempenho (storage) e sistemas de processaarmazena-mento baseado em lâminas. Em relação aos equipamentos de storage, existe cerca de 60 TB de espaço disponível, dos quais cerca de 2 TB podem ser imediatamente alocados ao projeto Smart Metropolis. Em relação à capacidade de processamento, existem um total de 156 núcleos com 2 TB de memória RAM, sem previsão de disponibilização de capacidade ao projeto.
O IMD oferece hoje o serviço IMDCloud, que é baseado no produto VMware Integrated OpenStack (VIO). Esta é uma customização da plataforma OpenStack para sua execução sobre uma infraestrutura VMware, exigindo diferentes tipos de licenças comerciais de acordo com a funcionalidade a ser ofere-cida. Foi feita uma análise acerca da utilização deste ambiente como base para a instância FIWARE de produção, e a conclusão é que o mesmo não é viável tecnicamente e não atende as demandas do projeto. Dentre os motivos identificados estão a necessidade de se utilizar tecnologias VMware como infra-estrutura base para a nuvem, que são incompatíveis com os requisitos apresentados pela plataforma FIWARE, como por exemplo, a impossibilidade de se utilizar o KVM como tecnologia de virtualização (um dos requisitos do FIWARE). Além disso, o IMD não possui licenças o suficiente para a capacidade que se deseja implantar para o projeto Smart Metropolis. Outro problema encontrado foi a falta de su-porte a IPs flutuantes, outro requisito da plataforma FIWARE. O ambiente atual exigiria a instalação de outro produto VMware, que talvez atendesse à demanda em relação a endereçamento IP. Entretanto, o IMD e a UFRN não possuem nenhuma licença deste produto que permitiria sua experimentação. Por fim, as ferramentas de instalação/operação deste ambiente não suportam a implantação de todos os serviços OpenStack, como por exemplo o serviço de armazenamento de objetos swift. Este fator foi conside-rado como bastante grave por todos os envolvidos, uma vez que exige esforço manual para a implanta-ção/operação de um ambiente em que ser prevê um crescimento ao longo do tempo. Outro ponto que chamou atenção foi a ausência de ferramentas de monitoramento no ambiente do IMDCloud.
A principal conclusão dessas análises é de que, no momento atual, a melhor opção é implantar um am-biente FIWARE separado do amam-biente em funcionamento no IMD. Caso esse amam-biente se mostre estável, pode-se considerar a desativação do IMDCloud e migração de seus clientes para a nuvem FIWARE, e consequente realocação de recursos físicos do IMDCloud para a instância FIWARE.
Baseado nas conclusões apresentadas, foi realizada outra análise acerca de quais recursos poderiam ser utilizados para a implantação do ambiente FIWARE. Em termos de processamento, um estudo deta-lhado acerca da alocação e distribuição de máquinas virtuais no Datacenter do IMD permitiu identificar uma lâmina com 24 núcleos de processamento e 160 GB de memória RAM. Em relação a armazena-mento, o storage do IMD pode ser utilizado para armazenamento de bloco e imagens, porém não existem servidores disponíveis para o serviço de armazenamento de objetos.
Com isso, consideramos também a utilização de parte dos recursos destinados à instância FIWARE de treinamento como infraestrutura base para a implantação de uma nuvem OpenStack que possa ser utilizada como instância FIWARE de produção. É importante ressaltar que esta decisão pode afetar os estudos com as outras ferramentas de operação da plataforma FIWARE, principalmente aquelas que envolvem mudanças significativas em serviços da infraestrutura. Além disso, existe também o risco de
que avanços nos estudos com as ferramentas de operação avancem possam trazer impactos à instância de produção.
4.2 Projeto de Implantação
O projeto de implantação propõe o planejamento de uma nuvem OpenStack que possa ser utilizada fu-turamente como uma instância Fiware de produção, utilizando o Fuel como ferramenta de deploy. Os experimentos feitos até o momento comprovaram a eficiência do Fuel, no que diz respeito ao provisiona-mento de um ambiente OpenStack. Além disso, essa ferramenta permite um rápido deploy e possui meios de verificar a corretude do ambiente. Devido a isso, e por ser um dos meios indicados pelo FIWARE para se criar um ambiente OpenStack, será optado por se utilizar o Fuel em sua versão 9.0, provisionando assim o OpenStack Mitaka.
O Planejamento leva em conta um ambiente escalável, atingindo futuramente uma arquitetura de alta disponibilidade. Nas seções abaixo serão descritos os recursos alocados para o projeto de implantação, bem como o ambiente proposto e a arquitetura de rede proposta.
4.2.1 Recursos Disponíveis
A tabela abaixo retrata os recursos a serem utilizados no ambiente de produção. Estão disponíveis um total de cinco servidores, três Dell PowerEdge R530, um Dell PowerEdge R730 e uma Lâmina do Data-Center do IMD.
Tabela 2: Descrição da infraestrutura disponível para o ambiente de produção.
Servidores 3 x Dell PowerEdge
R530
1 x Dell PowerEdge R730
1 x Lâmina
Processador Intel XeonR E5-2620R v3 2.4GHz 6 núcleos
Intel XeonR E5-2630R
v3 2.4 GHz 8 núcleos
2 x Intel Xeon X5650 2.66 GHz 6 núcleos
Memória 16 GB 128 GB 160GB
Armazenamento 2 discos de 1 TB SATA 8 discos SAS de 600 GB Até 2TB
Rede 4 x NetXtreme BCM5720
Gigabit Ethernet PCIe
4 x NetXtreme BCM5720 Gigabit Ethernet PCIe
4 Placas de Rede
Na próxima seção será exposto como esses servidores serão utilizados e qual será o papel de cada um deles no ambiente OpenStack a ser provisionado.
4.2.2 Ambiente Proposto
O ambiente, apesar dos seus recursos limitados, foi planejado visando escalabilidade, além de ser pos-sível, com a adição de mais nós, atingir uma arquitetura de alta disponibilidade e redundância, o que é essencial para o FIWARE.
Como visto na seção de recursos, temos três servidores Dell PowerEdge R530 disponíveis, ele serão referenciados ao longo da seção como R530-1, R530-2 e R530-3. O R530-1 terá como sistema operaci-onal a distribuição GNU/Linux CentOS e como hypervisor o KVM. Além disso, ele irá virtualizar dois servidores, o primeiro que será o Fuel Master e o segundo que será o Controller do ambiente OpenStack. O servidor R530-2, por sua vez, irá desempenhar o papel de Storage, executando os serviços relacionados
ao Swift, Object Storage, e ao Cinder Block Storage. Por fim, o Dell R530-3 desempenhará o papel de Storagee também executará o Telemetry, serviço de monitoramento, métricas e alarmes do OpenStack.
Já os servidores DellPowerEdge R730 e a lâmina irão desempenhar o papel de Compute do ambiente. Isso se deve ao fato de ambos possuírem melhores aspectos de configuração, isto é, possuem um melhor processamento e têm uma quantidade significativa de memória RAM, permitindo um maior número de instâncias do que os demais nós. A tabela 3 abaixo retrata o ambiente descrito.
Tabela 3: Ambiente de produção proposto.
Papéis Servidores Configurações Descrição
Fuel Dell PowerEdge R530-1
CPU: 4 núcleos Disco: 128GB Memória: 4GB
O Fuel será virtualizado no servidor Dell R530-1
OpenStack Controller Dell PowerEdge R530-1
CPU: 4 núcleos Disco: 2x300GB
Memória: 8GB
O Openstack Controller será virtualizado no servidor
Dell R530-1
.
OpenStack Storage Dell PowerEdge R530-2 Dedicado
-OpenStack Storage /
Telemetry Dell PowerEdge R530-3 Dedicado
-Openstack Compute Dell PowerEdge R730 Dedicado
-Openstack Compute Lâmina Dedicado
-Para o ambiente ter uma certa redundância, o servidor Dell R530-1 utilizará os seus dois discos de 1TB em RAID1. Dessa forma, o servidor utilizará um disco para armazenar os seus dados, e o outro disco para replicar os mesmos. Assim, em caso de falha de um dos discos, o ambiente não será comprometido. Os servidores que desempenham o papel de Storage irão utilizar os discos em JBOD. Assim, caso um disco falhe, os demais não serão comprometidos, o que aconteceria se fosse optado por se utilizar o RAID0. Por fim, os nós que desempenham o papel de Compute irão utilizar os discos em RAID0 para uma melhor performance.
4.2.3 Planejamento de Rede
O ambiente OpenStack proposto será constituído por um total de sete servidores, sendo cinco deles físicos e dois deles virtualizados. Os servidores físicos serão compostos por três Dell PowerEdge R530, um Dell PowerEdge R730 e uma lâmina do datacenter do IMD.
Como visto na figura 6, os nós smart-ctrl e fuel-master irão constituir o ambiente virtual. Nesse con-texto, as redes Management, Private e Storage serão acessíveis a este ambiente através da bridge br-mps, presente no servidor smart, e todo o tráfego oriundo dessas redes e destinado à elas, irão trafegar por meio dessa interface. Assim, temos que por meio da bridge br-mps, serão criadas três interfaces lógicas de rede, a serem utilizadas pelo servidor smat-ctrl, designadas para o tráfegos das redes já citadas. Por fim, as redes Admin PXE e Public / Floating serão acessíveis através das suas bridges exclusivas, isto é, das interfaces br-pxe e br-ex respectivamente, e por meio dessas interfaces, serão criadas as interfaces lógicas correspondentes a tais redes.
Os servidores smart-str01, smart-str02, smar-comp01 e smart-comp02 também possuem quatro inter-faces físicas de rede. As cinco redes utilizadas pelo Fuel serão distribuídas da seguinte maneira em suas interfaces:
Figura 6: Arquitetura de rede proposta para o ambiente de produção.
• Bridge br-pxe. Criada pelo Fuel, essa bridge utilizará a interface física de rede em1. Nessa bridge, irão trafegar os dados da rede administrativa PXE.
• Bridge br-ex. Criada pelo Fuel, essa bridge utilizará a interface física de rede em2. Nessa bridge, irão trafegar os dados das redes Pública e Flutuante.
• Bridge br-management. Criada pelo Fuel, essa bridge utilizará a interface física de rede em2. Nessa bridge, irão trafegar os dados das rede de Gerenciamento.
• Bridge br-mesh. Criada pelo Fuel, essa bridge utilizará a interface física de rede em3. Nessa bridge, irão trafegar os dados da rede Privada.
• Bridge br-storage. Criada pelo Fuel, essa bridge utilizará a interface física de rede em4. Nessa bridge, irão trafegar os dados da rede de Armazenamento.
Como ainda pode ser visto na figura 6, as redes de Gerenciamento, Privada e de Armazenamento irão utilizar VLANs com os identificadores 1001, 1002 e 1003, respectivamente. Essas redes já se encontram criadas no switch do datacenter em que o ambiente está conectado. Além disso, essas redes são acessíveis apenas por meio da VLAN dedicada ao projeto, isto é, da rede 10.7.49.0/24.
4.3 Discussão
Com os atuais recursos alocados para o estudo da plataforma FIWARE, não foi possível, a priori, arqui-tetar um ambiente com alta disponibilidade (High Availability — HA), já que um ambiente desse tipo demanda mais recursos. Porém, o ambiente proposto é escalável, o que significa que com a adição de mais dispositivos, o ambiente pode ser moldado em uma arquitetura que ofereça alta disponibilidade,
confiabilidade e redundância. Dada a restrição de recursos, recomendamos um estudo mais aprofundado acerca de quais serviços OpenStack e FIWARE serão utilizados pelos membros do projeto, permitindo assim um redimensionamento da nuvem de forma a priorizar esses serviços.
5 Considerações Finais
De acordo com o cronograma definido, apresentado no relatório entregue ao fim do primeiro trimestre de projeto, duas tarefas principais foram elencadas para este segundo trimestre:
1. estudo da plataforma FIWARE, com a implantação da mesma em ambiente experimental; e 2. projeto e planejamento para a implantação da instância FIWARE de produção no ambiente
com-putacional do IMD.
Diversas interações com as equipes de TI do IMD e da SINFO, membros de outros WPs, e a coorde-nação do projeto foram realizadas ao longo da execução destas tarefa, de modo que as decisões tomadas consideram as discussões realizadas.
Em uma análise geral, consideramos que os objetivos elencados para o WP-Infraestrutura foram alcan-çados parcialmente. Isso acontece devido à realocação de uma das bolsistas do WP-Infraestrutura para colaborar em tarefas do WP-Middleware. Tal realocação impactou nas atividades realizadas no sentido de, termos menos recursos humanos dedicado às tarefas do WP-Infraestrutura, e de eventuais interrup-ções nas atividades dos outros membros da equipe para auxiliar em tarefas ligadas ao WP-Middleware.
No tocante ao estudo da plataforma FIWARE e de ferramentas de operação, julgamos que os objetivos definidos para este trimestre foram alcançados parcialmente. Através de interações com membros do WP-Middleware, e da equipe de TI do IMD, o foco deste estudo foi direcionado às ferramentas de implantação. Ao longo do trimestre, fomos capazes de implantar uma nuvem OpenStack que atenda aos requisitos da plataforma FIWARE em termos de serviços OpenStack em execução e tecnologia de virtualização. Atingimos um nível de familiaridade com a ferramenta Fuel que nos permitiu não somente a implantação de diferentes ambientes OpenStack operacionais, mas também a contribuição direta para a comunidade OpenStack através da submissão de correções em um dos plugins do Fuel.
Embora os experimentos envolvendo o nova-docker não foram concluídos, isso não afeta os resultados alcançados em relação às orientações fornecidas pela documentação FIWARE. Isso acontece devido ao fato de que todos os serviços indicados como requeridos foram instalados com sucesso, enquanto que os serviços relacionados ao suporte de containers docker está indicado como ferramentas a serem adicionadas em um futuro próximo. Entretanto, o oferecimento desse serviço apresenta um potencial impacto em uma instância a nível de produção, tanto a nível de configuração das ferramentas e serviços, como à alocação de recursos computacionais.
No tocante ao projeto da instância FIWARE de produção, consideramos que os objetivos definidos não foram alcançados em sua totalidade. Isso acontece devido à falta de recursos computacionais para a implantação de uma instância FIWARE de produção de acordo com a arquitetura proposta em sua documentação oficial. De maneira a superar a ausência de recursos computacionais, a proposta de projeto apresentada neste relatório considera parte dos recursos alocados à instância FIWARE de treinamento de modo a termos uma instância FIWARE o mais próxima o possível de um cenário de produção. O objetivo é possibilitarmos a execução das aplicações em desenvolvimento, e seus respectivos GEs, em uma configuração próxima à real.
Embora tenhamos uma restrição de recursos computacionais, o projeto foi desenhado com atenção à questões de alta-disponibilidade e escalabilidade. Desse modo, o ambiente pode ser facilmente escalado com a adição de novos recursos.
Um ponto que merece uma consideração adicional é em relação à disponibilidade de endereços IP públicos, que possam ser acessíveis de fora da rede da UFRN. Uma proposta de solução encaminhada junto à SINFO envolve a alocação de uma faixa de endereçamento exclusiva para ser alocada ao projeto, tendo no momento a alocação de 10 endereços para fins de experimentação. Além disso, aspectos relaci-onados à configuração do sistema de resolução de nomes (DNS) a ser utilizado ainda precisa ser melhor definida.
Em seguida apresentamos uma descrição das próximas atividades a serem desenvolvidas pelo WP Infraestrutura visando atingir aos objetivo de Desenvolvimento, implantação e operação de Infraestrutura Computacional:
• Finalização dos testes com plugin nova-docker e seu uso para testes com ambientes de geren-ciamento de containers. É necessário identificar uma estratégia para o gerengeren-ciamento de GEs e aplicações baseada em containers sobre uma nuvem OpenStack.
• Estudos e experimentos com as outras ferramentas disponibilizadas pelo capítulo OPS Tool: OPS-Dash, OPS-Health e OPS-Toolkit.
• Estudos sobre implantação de GEs em ambiente de produção. Esta tarefa envolverá interações com o WP-Aplicações de maneira a: (1)Identificar o conjunto de GEs sendo utilizadas pelas aplicações em desenvolvimento; (2)priorizar um sub-conjunto de GEs baseado no potencial impacto de suas aplicações clientes; (3)Estudo aprofundado das GEs de maior impacto potencial com vistas à sua implantação a nível de produção.
• Implantação de uma instância FIWARE para ser utilizada pelos membros do projeto (com foco no WP-Aplicações). É importante salientar que esta instância estará sujeita à intervenções decorrente dos outros estudos realizados pelo WP-Infraestrutura.
Dada a curva de aprendizado envolvida no treinamento de um administrador para uma infraestrutura de nuvem, recomendamos a alocação de mais um bolsista com esse papel, de maneira a evitar que a instância FIWARE pare de funcionar por falta de mão de obra qualificada para operá-la.
Referências
[1] FIWARE OPS Tools, Disponível em http://wiki.fiware.org/FIWARE_OPS_Tools, acessado em 30/07/2016.
[2] FIWARE Lab Nodes Handbook, Disponível em http://wiki.fiware.org/FIWARE_Lab_ Nodes_Handbook, acessado em 30/07/2016.
[3] Ferramenta Fuel, Disponível em https://wiki.openstack.org/wiki/Fuel, acessado em 30/07/2016.
[4] FIDASH: FIWARE’s Cloud Dashboard, Disponnível em https://github.com/fidash/ fiware-fidash, acessado em 30/07/2016.
[5] SLA Framework, Disponível em https://github.com/Atos-FiwareOps/
sla-framework, acessado em 30/07/2016.
[6] SLA Dashboard, Disponível em https://github.com/Atos-FiwareOps/
sla-dashboard, acessado em 30/07/2016.
[7] Calendar Widget, Disponível em https://github.com/fidash/widget-calendar, acessado em 30/07/2016.
[8] FIWARE Health - Sanity Checks, Disponível em https://github.com/telefonicaid/
fiware-health/tree/develop/fiware-region-sanity-tests, acessado em
30/07/2016.
[9] FIWARE Health - Sanity Check Status Dashboard, Disponível em https://github.
com/telefonicaid/fiware-health/tree/develop/dashboard, acessado em
30/07/2016.
[10] FI-Lab Infographics, Disponível em https://github.com/SmartInfrastructures/ fi-lab-infographics, acessado em 30/07/2016.
[11] FIWARELab - Federation Monitoring API Component, Disponível em https://github.com/ SmartInfrastructures/FIWARELab-monitoringAPI, acessado em 30/07/2016. [12] Flavor sync, Disponível em https://github.com/Atos-FiwareOps/flavor-sync,
acessado em 30/07/2016.
[13] Maintenance calendar API, Disponível em https://github.com/Atos-FiwareOps/ fiware-maintenance-calendar-api, acessado em 30/07/2016.
[14] GlanceSync - Glance Synchronization Component, Disponível em https://github.com/ telefonicaid/fiware-glancesync, acessado em 30/07/2016.
[15] FIWARE Trial Users Management, Disponível em https://github.com/telefonicaid/ fiware-skuld, acessado em 30/07/2016.
[16] FIWARE Aiakos, Disponível em https://github.com/telefonicaid/
SMART METROPOLIS- INFRAESTRUTURA COMPUTACIONAL
Smart Hot-Spot
1 1. Introdução ... 2 2. Montagem do Smart Hot-Spot ... 3
2.1 Descrição dos componentes ... 3 2.1.1 Módulo Solar ... 3 2.1.2 Controlador ... 3 2.1.3 Bateria ... 4 2.1.4 Estrutura física ... 5 2.2 Montagem ... 5 2.3 Dificuldades e soluções ... 7 3. Monitoramento de energia ... 7 3.1 Descrição ... 7 3.2 Previsões e coleta de dados ... 10 3.3 Análise de resultados ... 13 3.4 Dificuldades e soluções ... 14
4. Sensoriamento ... 16
4.1 Descrição ... 16 4.2 Especificação ... 16 4.2.1 Charger controller 20A ... 16 4.2.2 Sensor de Gás e Fumaça MQ-2 ... 16 4.2.3 Beaglebone Black ... 17 5. Redes ... 19 5.1 Descrição ... 19 5.2 Estrutura de Interconexão ... 19 5.2.1 NanoStation M5 ... 19 5.2.2 PowerBeam ... 20 5.2.3 NanoStation M2 ... 20 5.2.4 NanoStation (NSM5) ... 21 5.2.5 NanoStation (NSM2) ... 22 5.2.6 PowerBeam (M5-300) ... 23 5.3 Topologia e configurações ... 24 5.4 Dificuldades e Soluções ... 25
