smartmetropolis – plataforma e aplicações para …...nuvem da plataforma fiware é baseada na...
TRANSCRIPT
Universidade Federal do Rio Grande do NorteInstituto Metrópole Digital
SmartMetropolis – Plataforma e Aplicações para Cidades Inteligentes
WP4 – Infraestrutura
Relatório de Atividades do Segundo Trimestre
Natal-RN, BrasilJulho/2016
Equipe TécnicaDocentes
Prof. Dr. Carlos Eduardo da Silva (Coordenador) – IMD/UFRNProf. MSc. Wellington Silva de Souza (CTC) - IMD/UFRNProf. MSc. Aluizio Ferreira da Rocha Neto - IMD/UFRNProf. Dr. Ivanovitch Medeiros Dantas da Silva - IMD/UFRN
DiscentesLuana Wandecy Pereira SilvaRafael Pereira ClementeRafael VarelaRoberia Silva da Penha LourençoThais Alves de Freitas
Pesquisadores vinculadosThomas Filipe da Silva Diniz - Anolis TIHiago Miguel da Silva Rodrigues - Anolis TI
Sumário1 Introdução 6
2 Desenvolvimento, implantação e operação de Infraestrutura Computacional 6
3 Estudo de Ferramentas de Operação da Plataforma FIWARE 83.1 Ferramenta de Implantação da Plataforma . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Ferramentas de Operação de Plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 Ferramenta de Análise da Plataforma-OPS-Health . . . . . . . . . . . . . . . . . . . . . 123.4 Ferramentas de Suporte - OPS-Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.5 Experimentos com as Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.1 Recursos Disponíveis e Metodologia . . . . . . . . . . . . . . . . . . . . . . . . 143.5.2 Experimento em Ambiente Virtualizado . . . . . . . . . . . . . . . . . . . . . . 153.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 224.1 Diagnóstico DataCenter IMD e análise baseada nos requisitos FIWARE . . . . . . . . . 234.2 Projeto de Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1 Recursos Disponíveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2.2 Ambiente Proposto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2.3 Planejamento de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 Considerações Finais 27
Lista de Figuras1 Arquitetura da ferramenta Fuel. Fonte: https://wiki.openstack.org/wiki/
Fuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Arquitetura em ambiente virtualizado utilizando um servidor de teste. . . . . . . . . . . 153 Arquitetura de rede projetada para o ambiente virtualizado. . . . . . . . . . . . . . . . . 164 Arquitetura utilizada no experimento com KVM. . . . . . . . . . . . . . . . . . . . . . 195 Arquitetura de rede utilizada no experimento com KVM. . . . . . . . . . . . . . . . . . 216 Arquitetura de rede proposta para o ambiente de produção. . . . . . . . . . . . . . . . . 26
Lista de Tabelas1 Descrição da infraestrutura disponível para os experimentos. . . . . . . . . . . . . . . . 142 Descrição da infraestrutura disponível para o ambiente de produção. . . . . . . . . . . . 243 Ambiente de produção proposto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6
1 Introdução
O projeto Smart Metropolis, conduzido pelo Instituto Metrópole Digital (IMD) da Universidade Federaldo Rio Grande do Norte (UFRN), tem como objetivo o desenvolvimento de soluções de tecnologia dainformaçã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 Pacotesde Trabalho (Work Packages - WP) temáticos, liderados cada por um coordenador. Cada WP possui umconjunto de objetivos a serem alcançados ao longo dos cinco anos de execução do projeto. Este relatórioestá inserido no contexto do WP 4 - Infraestrutura Computacional, que no contexto do primeiro ano deexecuçã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 ainfraestrutura computacional do projeto, assim como todos os aspectos relacionados à implantaçãode 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 (Coordenadorda 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-spotdeverá 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 deSouza, 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 eoperaçã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 apresentadasem 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 macropara 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 emnuvem da plataforma FIWARE é baseada na plataforma Openstack, esta atividade envolve o estudo
7
e experimentação com os diversos componentes da plataforma de nuvem OpenStack em ambientevirtualizado, incluindo ferramentas de operação.
2. Estudo da plataforma FIWARE (ferramentas de operação): Esta atividade tem como foco oestudo e experimentação com as ferramentas de operação da plataforma FIWARE em ambientevirtualizado.
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 parao 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 aexperimentação com esses componentes de modo a demonstrar seu funcionamento. Esta atividadenão estava inicialmente prevista para o primeiro ano de execução do projeto, e foi incluída ao finaldo primeiro trimestre, como apoio às atividades do WP-Middleware.
5. Projeto e planejamento de implantação de instância FIWARE de produção: Esta atividadetem como objetivo a definição do projeto de implantação da instância FIWARE de produção noambiente computacional do IMD.
No início do segundo trimestre de execução do projeto foram realizadas algumas reuniões envolvendoa 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 seremrealizadas. 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 umasobre-posição referente a esta tarefa com um dos tópicos de estudo do WP-Middleware, de forma quea mesma foi desconsiderada pelo WP-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ânciaseria implantada diversas vezes com configurações e topologias diferentes, de forma que não fazia maissentido uma tarefa exclusiva para tal. Desse modo, a instância de treinamento, mais especificamente osrecursos 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 peloWP-Middleware. É importante mencionar que esta mudança resultou na realocação da bolsista RoberiaSilva da Penha Lourenço de atividades diretamente relacionadas ao WP-Infraestrutura para atividades doWP-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-Infraestruturaao longo do segundo trimestre do projeto foram agrupados em duas tarefas, que serão sumarizadas nasequência (e estão detalhadas neste relatório):
8
1. Estudo da plataforma FIWARE (ferramentas de operação): Esta tarefa envolveu o estudo dasferramentas 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 destatarefa é de elaborar um projeto de implantação básico para a instância FIWARE de produção noambiente computacional do IMD. Ela envolveu diversas interações com as equipes de TI do IMDe 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 umou 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 OPSTools [1], responsável pelo desenvolvimento de um conjunto de ferramentas que suportam as operaçõesde 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 umainstâ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 coma 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 aseguir:
• Ferramenta de Implantação de Plataforma (OPS-Deploy): tarefa dedicada às ferramentas deimplantaçã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 ferramentasque melhor se adequam ao ambiente computacional disponível considerando o expertise da equipe deimplantação.
9
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 experimentos seconcentraram 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 Estudoda plataforma FIWARE (ferramentas de operação), e consistiu na experimentação realizada com asferramentas de operação, onde diversas instâncias FIWARE/OpenStack foram implantadas de modo apermitir à 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 dePlataforma (OPS-Deploy). Concluímos essa seção com uma breve descrição das próximas atividades aserem 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 aimplantação de uma instância FIWARE:
1. Configuração manual: Consiste em seguir as instruções de instalação de uma nuvem OpenStackde acordo com sua documentação oficial.
2. Ferramenta de implantação Fuel: Consiste em uma ferramenta de código livre para a implantaçãode nuvens OpenStack.
3. Ferramenta de implantação OPS-Deploy: Consiste em um conjunto de plugins Fuel, junto comalgumas outras alterações, para a implantação de uma instância da plataforma FIWARE de acordocom sua arquitetura de referência.
O critério de escolha acerca de qual opção utilizar depende principalmente do nível de customizaçãodesejada 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 pelaferramenta 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, foidecidido explorar as ferramentas Fuel e OPS-Deploy. Foi dada maior ênfase a ferramenta Fuel, uma vezque 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 emlarga escala. Dentre suas principais características, podemos citar o suporte a descoberta e configuraçãode novos hardware, o gerenciamento a diferentes nuvens OpenStack com suporte a configurações come sem alta-disponibilidade, testes pre- e post- implantação, e uma interface Web para a visualização doambiente e de logs em tempo real.
O Fuel é composto por vários componentes independentes. Alguns desses componentes são específicosdo Fuel, enquanto outros são serviços de terceiros(Cobbler, Puppet, Mcollective, Astute e Nailgun). Suaarquitetura é mostrada na Figura 1.
O usuário consegue interagir com o Fuel utilizando uma interface Web, ou linha de comando (WebUI/CLI). Keystone representa o mecanismo de controle de acesso da plataforma OpenStack, onde osusuários da ferramenta são cadastrados. O componente principal do Fuel é o Nailgun, responsável pelo
10
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 deredes, 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 deagentes capazes de executar as ações e configurações solicitadas pelo Nailgun. Astute utiliza o Cobblerpara a realização de provisionamento, sendo responsável por controlar os serviços de DHCP e TFTP darede, afim de inicializar a gestão dos nós, iniciando e instalando o sistema operacional nos nós, com todasas definições que foram configuradas. Um conjunto de script (MCollective) são inicializados em todos osnó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 oambiente. Com ele podemos criar agentes MCollective para gerenciar outras estruturas de gerenciamentode configurações dos nós. O OSTF (OpenStack Testing Framework é um componente adicional que podeser 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 implantare 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 daatribuição de endereços IP para os Fuel Slave nodes.
• Fuel Slave node: consiste em um servidor que será provisionado pelo Fuel Master node. Esteservidor 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 emtermos de diferentes redes isoladas uma das outras, e a instalação de um nó Fuel Master. Uma vez queo Fuel Master esteja em funcionamento, servidores que serão utilizados como infraestrutura da nuvemOpenStack podem ser adicionados à mesma rede do Fuel Master, tornando-se nós Fuel Slave. Essesnós são automaticamente detectados pelo Fuel Master, e podem então ser configurados por meio de suainterface de acesso.
O Fuel suporta também a extensão de suas funcionalidades através de um conjunto de plugins. Existeuma gama de plugins disponíveis, incluindo plugin relacionados a rede (possibilitando a provisão de
11
firewall como serviço), monitoramento (permitindo a integração com outras ferramentas de monitora-mento como o Zabbix), armazenamento (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árioWeb para sua adaptação ao estilo similar ao utilizado pela FIWARE, e um conjunto de plugins específicospara a instalação de GEs do FIWARE. A versão atual do OPS-Deploy (4.0) é baseada na versão 7.0 doFuel, suportanto a instalação da release Kilo (2015.1.0-7.0) do OpenStack em um sistema operacionalUbuntu 14.04. De acordo com seu repositório oficial1, esta versão recebeu sua última atualização em 26de 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á seencontra 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 umpainel 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, permitindoassim, 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, configuraro layout, alem de modificar o seu comportamento.
Para dar apoio a algumas ações, os Widgets possuem APIs baseadas nos serviços oferecidos peloOpenStack, 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 pelagestã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 outroscomponentes. 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 parauso, que pode ser livremente modificado. Além dos serviços já oferecidos pelo dashboard oficial doOpenStack, o FIDASH traz um conjunto de widgets com funcionalidades extras, algumas específicaspara 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 componentepermite o gerenciamento de todo o ciclo de vida de SLAs, desde a criação de templates, ate a detecçãode violação. O SLA Manager é baseado em plugins, podendo ser adaptado e extendido para ser utilizadoem diferentes plataformas. O SLA Dashboard [6], fornece uma interface de usuário Web, que permite ogerenciamento de todo o ciclo de vida de SLA, expondo as operações do SLA Manager (que atua comoback-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/2WireCloud é uma GE oferecida pelo capítulo técnico de Applications and Services Ecosystem and Delivery Framework
12
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, porexemplo usuário ou alguma ferramenta OPS-Health. Ele consegue separar os eventos entre as regiões, eapoia 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 anuvem 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áriopode 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áriosa 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çõesgrá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 desanidade ao longo de cada instância FIWARE, permitindo identificar o estado atual de uma instânciaFIWARE. Esta ferramenta é dividida em um componente de back-end (Sanity Check Engine [8]) e umcomponente de front-end (Sanity Check Dashboard [9]). Além de oferecer um conjunto de casos detestes, e coordenar sua execução através de seu componente de back-end, a ferramente apresenta umavisualização gráfica dos resultados dessas execuções. A Sanity Check Dashboard mostra uma visão geralde todos os testes realizados e os status de cada instância FIWARE, mostrando registros detalhados paraos teste que falharam. Esta ferramenta permite que os usuários e administradores saibam facilmente quaisrecursos 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-sidee 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 aoperaçõ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).
13
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 utilizadaem 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çãode informações de “flavors” particulares, assim como a instalação de outros “flavors” públicos em suapró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 quevários clientes acessem e compartilhem informações sobre eventos, suportando também a utilização dediversos servidores de calendário. A ferramenta permite a indicação de janelas de manutenção, quando ainfraestrutura poderá estar indisponível, assim como de janelas de não-manutenção, que indica períodosno 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áquinavirtual em uma nuvem OpenStack. Este componente simplifica a sincronização de imagens gerenciadapelo 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 bibliotecasOpenStack. 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 derecursos alocados a usuários temporários após a expiração de suas contas. O propósito é garantir querecursos alocados a usuários de testes possam ser disponibilizados a outros usuário ao fim do período detestes. 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 faznecessário pois toda máquina virtual instanciada é acessível através de chaves públicas, uma para cadausuário que acessa o sistema, permitindo assim um acompanhamento de quais usuários acessam quaismá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 membrodo WP-Middleware Arthur Cassio, decidiu-se focar os experimentos nas ferramentas de implantaçãoda plataforma. Outro motivo para esta decisão é o impacto que tais ferramentas trazem ao projeto deimplantaçã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 aferramenta OPS-Deploy é fortemente baseada no Fuel, tendo como diferença um conjunto de pluginse customização voltadas para a plataforma FIWARE, julgamos mais importante conhecer a ferramentabase, que permite a aplicação de plugins conforme a necessidade do ambiente a ser configurado. Dessemodo, os plugins disponibilizados pelo OPS-Deploy podem ser facilmente aplicados ao Fuel, se assimjulgar-se necessário.
Além disso, foram realizados alguns experimentos preliminares com a ferramenta OPS-Deploy porparte do membro da equipe do WP-Middleware Arthur Cassio no contexto de uma instância FIWAREpara ser utilizada para desenvolvimento, e a mesma se mostrou problemática. O OPS-Deploy apresentoualgumas dificuldades para sua instalação e implantação da plataforma de nuvem, e após implantada,
14
instâncias criadas não eram acessíveis. Como solução, as GEs utilizadas para desenvolvimento foramimplantadas 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 entreelas ou aos serviços de nuvem do IMD. Este foi outro fator motivador para decidirmos explorar o Fuelem 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, queindica 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 é, oFuel 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 naimplementaçã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çãoda 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 doprojeto 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 umadescriçã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 impactaramnos 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 servidoresDell PowerEdge 530. A configuração desses servidores é apresentada na Tabela 1. A forma em comoesses 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
ProcessadorIntel R© Xeon R© E5-2620
v3 2.4GHz 6 núcleosIntel R© Xeon R© E5-2630
v3 2.4 GHz 8 núcleosMemória 16 GB 128 GBArmazenamento 2 discos de 1 TB SATA 8 discos SAS de 600 GBRede 4 x NetXtreme BCM5720 Giga-
bit Ethernet PCIe4 x NetXtreme BCM5720 Giga-bit Ethernet PCIe
A utilização do Fuel para a implantação de uma nuvem OpenStack pode ser resumida em quatropassos:
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 umaconfiguração diferente, o detalhamento das configurações serão apresentadas em suas respectivasseções.
15
2. Instalação e configuração do servidor Fuel master: envolve a instalação de sistema operacionalbaseado 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 precisamentã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 formaautomática pela ferramental Fuel, e na realização de um conjunto de testes para verificar a corretaimplantaçã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 realizadoem um ambiente totalmente virtualizado.
Da Estrutura e Ambiente de Testes Os testes iniciais foram realizados em um servidor DellPowerEdge 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 QEMU 3 como hypervisor. Via QEMUfoi virtualizado todo o ambiente de testes, isto é, o Fuel 7 e as máquinas que compõem o ambienteOpenStack.
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ãogerenciadas pela equipe do projeto, e foram criadas com o objetivo de simular uma infraestrutura a ser
3Emulador e virtualizador genérico open source de máquinas virtuais
16
utilizada por uma nuvem OpenStack. Segue abaixo uma breve descrição das máquinas que compõemesse 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 executaro cinder-volume e de prover serviços de containers, accounts e objects, além gerenciar o banco dedados de tais serviços;
• Ceilometer. Responsável por executar o banco de dados NoSQL MongoDB, para armazenar asestatísticas e dados coletados do ambienteStack OpenStack.
É importante salientar que esse ambiente segue os requisitos definidos pela plataforma FIWARE, quedefine um conjunto mínimo de serviços que precisam ser oferecidos por uma nuvem OpenStack para quea 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 seufuncionamento. Deve-se levar em conta que a definição dessas cinco redes determinadas pelo Fuel servepara segregar o tráfego, evitando assim problemas relacionados à segurança e desempenho. As cincoredes 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 doambiente OpenStack;
17
• 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, demensagens AMQP e serviços de alta disponibilidade, além do tráfego iSCSI entre os nós computee 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 libvirt 4. Basicamente, trata-sede um software definido em um host, que permite que uma ou mais máquinas virtuais se comuniquematravé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 àsmaquinas à rede do IMD. Para um melhor entendimento, será descrito em seguida como as redes foramdefinidas 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, comexceçã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 PXEe outra para a rede pública.
O uso de vlans (Virtual Local Area Network) nesse contexto é opcional. Isso se deve ao fato de quenesse ambiente utilizamos uma placa de rede dedicada para cada uma das redes, dispensando assim ouso de identificadores nos dados trafegados. Deve-se levar em consideração que a rede PXE não devereceber nenhuma tag (identificador de vlan), de modo a permitir a inicialização (boot) de servidores viarede.
Descrição do Ambiente OpenStack A figura 3 retrata as máquinas virtuais utilizadas no ambienteOpenStack 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 gerenciara operação da nuvem, além de mecanismos de controle de acesso. Esse nó executa os seguin-tes serviços do OpenStack: nova-scheduler, nova-api, nova-conductor, nova-consoleauth, nova-novncproxy, cinder-api, cinder-scheduler, glance, neutron-server, neutron-l3-agent, neutron-dhcp-agent, neutron-metadata-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 estamáquina é virtualizada. Executa os seguintes serviços: nova-compute, e neutron-agent.
4http://wiki.libvirt.org/page/VirtualNetworking
18
• smart-str. Desempenha o papel de Object Storage e Block Storage. Esse nó executa os seguintesserviç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 portantoroda 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 (healthchecks) que permite verificar a funcionalidade da nuvem implantada. Estes testes oferecem informaçõesde 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, com384 megabytes de memória RAM e 20 gigabytes de armazenamento e duas interfaces de rede, uma parao 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 doambiente OpenStack provisionado pelo Fuel.
Problemas encontrados O processo de instalação do Fuel Master ocorreu sem problemas, porémo 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 tevecontinuidade e foi finalizado com sucesso.
É importante levar em conta alguns pontos antes da realização de um deploy, tais pontos são cruciaispara 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 elese 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 ambientemais 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 pelaplataforma FIWARE. Uma outra diferença foi a utilização da versão community do Fuel. Baseado nosproblemas encontrados com o Fuel 7.0, foi optado por se utilizar a versão 9.0, sendo esta a última releaseestá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
19
discos de 500GB, enquanto que o segundo utilizava apenas um disco de 500GB. A Figura 4 apresentaa 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. Comomencionado 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 derede, imagem, scheduler e volume;
– Storage I / Storage II. Nó Block storage e Object storage, sendo responsável por executar ocinder-volume e de prover serviços de containers, accounts e objects, além gerenciar o bancode dados de tais serviços;
– Ceilometer. Responsável por executar o banco de dados NoSQL MongoDB, para armazenaras estatísticas e dados coletados do ambienteStack OpenStack.
• Servidor smart-comp: Corresponde ao nó de compute, executando o nova-compute diretamentesobre o sistema operacional da máquina física. As máquinas virtuais que rodam nesse servidor sãotodas 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
20
uso de tags, isto é, de identificadores nas vlans, fez-se necessário para a identificação do tráfego de cadauma 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 donó 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, pelasseguintes 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 é umabridge utilizada pelas redes Management, Private e Storage, assim todo o tráfego proveniente dessasredes trafega por essa interface, possibilitando a comunicacão entre os nós do ambiente. O servidorsmart adotou o seguinte arranjo:
• br-pxe. Bridge que utiliza a interface física em2 do servidor. Utilizada pela rede administrativaPXE;
• 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 ambientevirtualizado, 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 aoperaçã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.
• smatr-db. Serve de back-end para o ceilometer, o serviço de monitoramento OpenStack.
21
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 heatlhchecks, 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áquinasexecutando 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 completamente 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 doarquivo /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 rapidamentesolucionados 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 essesrecursos, 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 vezque o mesmo não estava documentado, e buscas em fórums da comunidade OpenStack se mostraraminfrutí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 equipepara tal.
22
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 primeirostestes confirmaram a possibilidade de se adicionar plugins Fuel em um ambiente de produção, que nãotinha 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 containersatravé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ão9 do Fuel devido às mudanças trazidas pela mesma. Assim, para que o plugin pudesse ser utilizado, foinecessário algumas alterações em seu código. Dessa forma, foi realizado um fork do repositório do pluginno GitHub, como também as alterações necessárias e a realização de um pull request. Com isso, o plugindo nova-docker se apresentou compatível. As alterações consistiram na mudança da especificação dasreleases do OpenStack suportadas, da versão do pacote do plugin e do Fuel, da restruturação de algumasarquivos, 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. Emborao 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 econtainers sobre esse ambiente.
É importante mencionar que as modificações realizadas pela equipe ao plugin Fuel foram submetidaspara 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 graude complexidade e custo considerável. Isso se dá devido aos requisitos para a operação de uma nuvemOpenStack, 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 nodocumento 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 atualdo ambiente computacional disponível no Datacenter do IMD. Com base nisso, reuniões envolvendoa equipe do projeto e a equipe de TI do IMD foram realizadas de forma a analisar os requisitos doFIWARE em relação aos recursos disponíveis no Datacenter do IMD, buscando maximizar a integraçãoentre a infraestrutura já existente com a infraestrutura a ser alocada para a instância FIWARE, além deconsiderar 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 coma adição de novos recursos.
23
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 noDataCenter do IMD. Este diagnóstico foi feito pela equipe de TI do IMD, mais especificamente peloProf. Itamir de Morais Barroca Filho e o Analista de suporte André Campos Bezerra. O detalhamentodeste 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 processamento baseado em lâminas. Em relação aosequipamentos de storage, existe cerca de 60 TB de espaço disponível, dos quais cerca de 2 TB podemser 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 decapacidade 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 infraestruturaVMware, 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 deproduçã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 plataformaFIWARE, 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 capacidadeque 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 deoutro produto VMware, que talvez atendesse à demanda em relação a endereçamento IP. Entretanto, oIMD 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çosOpenStack, 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 quechamou 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 ambiente em funcionamento no IMD. Caso esse ambiente se mostre estável,pode-se considerar a desativação do IMDCloud e migração de seus clientes para a nuvem FIWARE, econsequente 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 poderiamser 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 identificaruma 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 existemservidores 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 FIWAREde treinamento como infraestrutura base para a implantação de uma nuvem OpenStack que possa serutilizada como instância FIWARE de produção. É importante ressaltar que esta decisão pode afetar osestudos com as outras ferramentas de operação da plataforma FIWARE, principalmente aquelas queenvolvem mudanças significativas em serviços da infraestrutura. Além disso, existe também o risco de
24
que avanços nos estudos com as ferramentas de operação avancem possam trazer impactos à instância deproduçã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. Osexperimentos 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 meiosde verificar a corretude do ambiente. Devido a isso, e por ser um dos meios indicados pelo FIWARE parase criar um ambiente OpenStack, será optado por se utilizar o Fuel em sua versão 9.0, provisionandoassim o OpenStack Mitaka.
O Planejamento leva em conta um ambiente escalável, atingindo futuramente uma arquitetura de altadisponibilidade. 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 umtotal 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 PowerEdgeR530
1 x Dell PowerEdgeR730
1 x Lâmina
ProcessadorIntel R© Xeon R© E5-2620
v3 2.4GHz 6 núcleosIntel R© Xeon R© E5-2630
v3 2.4 GHz 8 núcleos2 x Intel Xeon X56502.66 GHz 6 núcleos
Memória 16 GB 128 GB 160GBArmazenamento 2 discos de 1 TB SATA 8 discos SAS de 600 GB Até 2TBRede 4 x NetXtreme BCM5720
Gigabit Ethernet PCIe4 x NetXtreme BCM5720
Gigabit Ethernet PCIe4 Placas de Rede
Na próxima seção será exposto como esses servidores serão utilizados e qual será o papel de cada umdeles 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ãoreferenciados 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 doisservidores, 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
25
ao Swift, Object Storage, e ao Cinder Block Storage. Por fim, o Dell R530-3 desempenhará o papel deStorage e 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 melhorprocessamento e têm uma quantidade significativa de memória RAM, permitindo um maior número deinstâ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-1CPU: 4 núcleosDisco: 128GBMemória: 4GB
O Fuel será virtualizadono servidor Dell R530-1
OpenStack Controller Dell PowerEdge R530-1CPU: 4 núcleosDisco: 2x300GBMemória: 8GB
O Openstack Controller serávirtualizado no servidor
Dell R530-1.
OpenStack Storage Dell PowerEdge R530-2 Dedicado -OpenStack Storage /
TelemetryDell 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 1TBem RAID1. Dessa forma, o servidor utilizará um disco para armazenar os seus dados, e o outro discopara 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 umdisco falhe, os demais não serão comprometidos, o que aconteceria se fosse optado por se utilizar oRAID0. Por fim, os nós que desempenham o papel de Compute irão utilizar os discos em RAID0 parauma melhor performance.
4.2.3 Planejamento de Rede
O ambiente OpenStack proposto será constituído por um total de sete servidores, sendo cinco delesfí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 pormeio dessa interface. Assim, temos que por meio da bridge br-mps, serão criadas três interfaces lógicasde rede, a serem utilizadas pelo servidor smat-ctrl, designadas para o tráfegos das redes já citadas. Porfim, 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 interfacesló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 suasinterfaces:
26
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. Nessabridge, irão trafegar os dados da rede Privada.
• Bridge br-storage. Criada pelo Fuel, essa bridge utilizará a interface física de rede em4. Nessabridge, 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ãoutilizar VLANs com os identificadores 1001, 1002 e 1003, respectivamente. Essas redes já se encontramcriadas no switch do datacenter em que o ambiente está conectado. Além disso, essas redes são acessíveisapenas 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 tipodemanda mais recursos. Porém, o ambiente proposto é escalável, o que significa que com a adição demais dispositivos, o ambiente pode ser moldado em uma arquitetura que ofereça alta disponibilidade,
27
confiabilidade e redundância. Dada a restrição de recursos, recomendamos um estudo mais aprofundadoacerca de quais serviços OpenStack e FIWARE serão utilizados pelos membros do projeto, permitindoassim 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 trimestrede 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 tomadasconsideram 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 paracolaborar em tarefas do WP-Middleware. Tal realocação impactou nas atividades realizadas no sentidode, 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 objetivosdefinidos para este trimestre foram alcançados parcialmente. Através de interações com membros doWP-Middleware, e da equipe de TI do IMD, o foco deste estudo foi direcionado às ferramentas deimplantação. Ao longo do trimestre, fomos capazes de implantar uma nuvem OpenStack que atendaaos requisitos da plataforma FIWARE em termos de serviços OpenStack em execução e tecnologia devirtualização. Atingimos um nível de familiaridade com a ferramenta Fuel que nos permitiu não somentea implantação de diferentes ambientes OpenStack operacionais, mas também a contribuição direta paraa 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 resultadosalcançados em relação às orientações fornecidas pela documentação FIWARE. Isso acontece devidoao fato de que todos os serviços indicados como requeridos foram instalados com sucesso, enquantoque os serviços relacionados ao suporte de containers docker está indicado como ferramentas a seremadicionadas em um futuro próximo. Entretanto, o oferecimento desse serviço apresenta um potencialimpacto 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 definidosnão foram alcançados em sua totalidade. Isso acontece devido à falta de recursos computacionais paraa implantação de uma instância FIWARE de produção de acordo com a arquitetura proposta em suadocumentação oficial. De maneira a superar a ausência de recursos computacionais, a proposta de projetoapresentada neste relatório considera parte dos recursos alocados à instância FIWARE de treinamentode modo a termos uma instância FIWARE o mais próxima o possível de um cenário de produção. Oobjetivo é possibilitarmos a execução das aplicações em desenvolvimento, e seus respectivos GEs, emuma configuração próxima à real.
28
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 escaladocom a adição de novos recursos.
Um ponto que merece uma consideração adicional é em relação à disponibilidade de endereços IPpúblicos, que possam ser acessíveis de fora da rede da UFRN. Uma proposta de solução encaminhadajunto à 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 melhordefinida.
Em seguida apresentamos uma descrição das próximas atividades a serem desenvolvidas pelo WPInfraestrutura visando atingir aos objetivo de Desenvolvimento, implantação e operação de InfraestruturaComputacional:
• 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 gerenciamento de GEs eaplicaçõ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 como WP-Aplicações de maneira a: (1)Identificar o conjunto de GEs sendo utilizadas pelas aplicaçõesem desenvolvimento; (2)priorizar um sub-conjunto de GEs baseado no potencial impacto de suasaplicações clientes; (3)Estudo aprofundado das GEs de maior impacto potencial com vistas à suaimplantação a nível de produção.
• Implantação de uma instância FIWARE para ser utilizada pelos membros do projeto (com foco noWP-Aplicações). É importante salientar que esta instância estará sujeita à intervenções decorrentedos outros estudos realizados pelo WP-Infraestrutura.
Dada a curva de aprendizado envolvida no treinamento de um administrador para uma infraestruturade nuvem, recomendamos a alocação de mais um bolsista com esse papel, de maneira a evitar que ainstância FIWARE pare de funcionar por falta de mão de obra qualificada para operá-la.
29
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, acessadoem 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 em30/07/2016.
[9] FIWARE Health - Sanity Check Status Dashboard, Disponível em https://github.
com/telefonicaid/fiware-health/tree/develop/dashboard, acessado em30/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/
fiware-aiakos, acessado em 30/07/2016.
SMART METROPOLIS- INFRAESTRUTURA COMPUTACIONAL
Smart Hot-Spot
Relatório 2
1
Sumário 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
2
1. Introdução
Neste segundo momento de produção, o grupo esteve focado na montagem do
Smart Hot-spot e testes em campo com este. Realizamos a montagem e ligação do protótipo
contando apenas com sua parte de energia, para que assim, fossem analisadas as melhores
condições para a montagem final. Enquanto os testes foram realizados na área externa, em
laboratório foi estudado melhor forma de alimentar o sistema, adaptações para ligações com
o Switch PoE, além da comunicação das antenas que serão responsáveis pelo sinal de Wi-fi
distribuído e o monitoramento do ambiente.
3
2. Montagem do Smart Hot-Spot
2.1 Descrição dos componentes
2.1.1 Módulo Solar
Para alimentação do Smart Hotspot foi utilizado um módulo de energia solar Renogy
Eclipse- 100 Watt 12 Volt Monocrystalline Solar Panel da Renogy, (Figura 1). Este módulo
monocristalino possui maior eficiência comparado ao policristalino e ao fio fino, cerca de 15%,
devido ao uso de um único cristal de silício para montagem, onde a pureza deste, traz
melhores resultados.
Figura 1: Módulo Solar
2.1.2 Controlador
Para checagem de parâmetros como corrente, tensão, porcentagem de bateria, está
sendo utilizador o controlador de carga EPSolar, que possui display multifuncional, que
permite adaptações e acompanhamento mais facilmente (Figura 2). Além de todas essas
4
funções, ele é o responsável por captar a energia que vem do módulo solar, carregar a bateria
e fornecer uma saída de 12V responsável por ligar os demais equipamentos.
Figura 2: Controlador de carga
2.1.3 Bateria
A medida que o módulo solar capta a energia, passará, através de corrente
contínua, e duas baterias chumbo-ácidas, consideradas mais econômicas, serão carregadas.
O modelo usado foi da marca Unipower, cada uma possui uma amperagem de 40A, uma
tensão de 12v (Figura 3).
Figura 3: Bateria
5
2.1.4 Estrutura física
Para proteger e englobar todo o sistema de controle, carga e alimentação, foi
construído em ferro, o poste, com uma coluna sustentada por uma base de quatro apoios,
fixos, e em seu topo, uma caixa devidamente isolada, porém facilmente acessível para
manutenção, onde ficarão as baterias, Switch PoE, sensores, controlador e a fiação em geral.
(Figura 4).
Figura 4: Estrutura do Poste
2.2 Montagem
Mediante a agregação de todos os componentes supracitados, foi montado um
poste onde este passou por algumas alterações com o passar do tempo, para que houvesse
garantia de acomodação dos componentes, alimentação e eficiência.
Situação 1:
O que se tinha previamente, era o poste montado em laboratório, com duas baterias
de 12v ligadas em série (Figura 5), para poder assim, ter alimentação suficiente para ligar os
equipamentos, tendo em vista que as tensões iriam se somar. Estávamos utilizando também
um controlador da Epsolar, o The Renogy Wanderer 20A PWM Charge Controller (Figura 5)
que nos passava algumas informações como estado da bateria e corrente, contudo, de forma
limitada pois não tínhamos uma visualização melhor dos dados, pois esses, eram passados
por sinais luminosos, de forma a dificultar a precisão das análises.
6
Todavia, foi percebido que o sistema montado não estava gerando os 24v de forma
constante, a corrente que estava fluindo era instável e insuficiente, o que deixaria espaço
para futuros erros, quando houvessem as montagens externas, podendo gerar danos aos
equipamentos utilizados
Figura 5: Conexão ao controlador e baterias
Situação 2 (atual):
Em seguida, após reuniões e pesquisas sobre a melhor forma de instalação, foi
decidido que colocar as baterias em paralelo (Figura 6) era o mais viável, para que assim, a
tensão de cada bateria permanecesse eficaz e isolada, e a corrente máxima fosse atingida, ao
somarmos de ambas as baterias, gerando uma alimentação mais eficaz dos equipamentos, o
que foi atingido com êxito. Para sanar o problema de voltagem, foi colocado um conversor de
tensão 12-24v para que o Switch PoE recebesse alimentação necessária. Por fim, foi utilizado
e modificado também, o controlador de carga, o que atualmente, é mais moderno, robusto,
interativo e fornece mais informações, o Renogy ViewStar 20 Amp PWM Solar Charge
Controller with LCD Display (Figura 6).
Figura 6 : Conexão ao controlador e baterias
7
2.3 Dificuldades e soluções
Ao ser montado e permanecer em laboratório, durante análises no ambiente, não
obtivemos problemas, devido à falta de interferências ao redor. Todavia, ao posicionar o
poste na cobertura, para obter uma avaliação real de todo o processo, foi percebido alguns
defeitos que foram bastante influenciados pelas mudanças de clima, principalmente.
Devido ao período de chuvas na cidade durante o final de junho e o início de julho,
ocorreram problemas com a estrutura e sustentação do protótipo, caso que levou a uma
reavaliação de todo o sistema e teve a base fortalecida para continuação de testes, de forma
temporária e será corrigida. Bem como ocorreu de constatarmos que devido a limitação do
dispositivo de rotação que foi construído para mudarmos de acordo com a preferência e
posição do sol, estava um pouco limitada e dificultando essa troca, e está sendo pensado uma
solução para rotacionar o painel de forma mais precisa e menos brusca usando a eletrônica,
paralelamente, em tarefas do nosso WP. No mais, a estrutura obteve um aproveitamento
satisfatório para testes e pretende-se melhorá-la cada vez mais.
3. Monitoramento de energia
3.1 Descrição
A parte de medição de energia na prática foi realizada a partir do final do mês de
junho, com acompanhamento diário dos bolsistas, em horários diferentes, para observar
como o sistema que continha um controlador, uma placa e duas baterias se comportavam. O
foco principal dessa etapa foi analisar carga e descarga de bateria, usando como principal
aliado nessas tarefas o controlador 20A, que possui visor para acompanhamento de diversos
parâmetros.
Ao analisar o controlador de carga, pôde-se coletar algumas informações relevantes
para o andamento do projeto, onde em seu visor, era possível acompanhar de forma direta
diversos dados (Tabela 1).
Parâmetro Função
PV Voltagem e amperagem em tempo real do sistema analisado
BATT Voltagem e amperagem em tempo real das baterias.
8
TEMP-SOC Temperatura atual da(s) bateria(s) e porcentagem de carga.
LOAD Voltagem e amperagem atual de carga.
DEVICE Condição geral do sistema.
SYSTEM STATUS Resumo dos parâmetros principais, supracitados, na tela principal.
Tabela 1: Parâmetros principais do controlador
Para uma leitura do Charger Controller pelo computador, é fornecida pela EPSolar o
software mostrado na figura 7. Nesse software é possível obter todas as informações do
controlador, como corrente na bateria, voltagem mínima, voltagem máxima, temperatura da
bateria, temperatura do dispositivo, status de dispositivo, além de um gráfico em tempo real
da voltagem.
Figura 7: Software Monitor Charger Controller
Para realizar a leitura de dados no computador, é necessário um cabo que faça a
conversão do RS485 para USB, sendo as conexões do RS485 feitas a partir do cabo RJ45. Para
realizar essa conexão utilizamos o cabo da figura 8 e o conector RJ45 T568A. Após muita
pesquisa e testes de conectividade com o multímetro, descobrimos que os fios verde e
9
marrom representam o VCC e GND, respectivamente. Descobrimos também que os fios azuis
e laranja são as conexões A e B. Porém há uma enorme divergência de informações na
internet e não encontramos qual fio representa qual conexão. Fizemos as duas tentativas,
invertendo os fios, mas não conseguimos obter a leitura de nenhuma das formas.
Figura 8 : Conexão RS485 para USB
Também foi tentada a utilização do shield conversor RS485 para Arduino, porém
mesmo fazendo as duas tentativas para os fios laranja e azul, não foi possível obter a leitura.
O shield utilizado está representado na figura 9.
Figura 9 : Shield RS485
10
Está sendo feito uma série de testes para descobrir o que está interferindo na leitura.
Temos possíveis causas, como por exemplo: cabo e shield danificados, o q acarretaria ser
necessário aterrar todos os fios que não estão conectados a nada. Quando conseguirmos
realizar essa leitura, teremos controle das informações do poste e poderemos utilizá-las na
nossa interface de gerenciamento.
3.2 Previsões e coleta de dados
O uso do sistema fotovoltaico leva em consideração a alta irradiação no Brasil e no
Nordeste, além de grande necessidade de implantar ideias sustentáveis de pequeno à médio
porte. O sistema montado no projeto trata-se de um sistema isolado, onde temos apenas um
módulo fotovoltaico, um acumulador, destinos para a carga e um dispositivo controlador de
carga para variar o uso de energia coletada e que circula apenas nesse ciclo e em futuros
equipamentos associados.
Diante mão, foram levados em consideração, alguns parâmetros importantes
(Tabela 2) de acordo com a norma da ABNT-NBR 10899 TB328- Conversão fotovoltaica de
energia solar.
Parâmetro Descrição
Radiação Densidade de fluxo energia da radiação solar (kW/m² ou mkW/m²)
Radiação direta Potência radiante do sol, recebida em uma unidade de área
Radiação difusa Potência radiante do céu, recebida em uma unidade de área
Global Potência radiante do sol, recebida em uma única unidade de área
em uma superfície horizontal (Global = direta + difusa)
Radiação total Potência radiante solar total, recebida em uma única unidade de
área em uma superfície inclinada.
Tabela 2: Parâmetros ABNT
11
O módulo é analisado com base em sua potência de pico (Wp), que no caso do
projeto é de 100W, analisado em condições padrão STC (Standard test conditions), onde a
radiação é de 1000W/m² e a temperatura é de 25º C e a partir disso relacionado a fatores
como, corrente da potência de pico (Imp), voltagem da potência de pico(Vmp), voltagem de
circuito aberto(Voc) e corrente de curto-circuito(Isc) (Figura 10).
Figura 10: Informações elétricas do módulo solar
Para entender e representar a eficiência e análise de desempenho, analisamos as
curvas PxV/IxV da placa (Figura 11), além da temperatura e irradiação da placa, que se diferem
apesar de serem diretamente proporcionais. Para isso, observamos graficamente (Figura 12),
que a ação da irradiação de certa forma, é mais importante para o desempenho do sistema,
pois a corrente máxima da potência de pico (Imp), aumenta de acordo com a irradiação e a
voltagem máxima da potência de pico (Vmp) permanece constante, enquanto na ação da
temperatura (Figura 13), vemos que seu aumento pouco altera a Imp e diminui a Vmp. Com
isso, em nas medições, houve um monitoramento de temperatura por meio do controlador
para que a eficiência fosse mantida e a irradiação fosse aproveitada com êxito.
Figura 11: Curvas IxV e PxV
12
Figura 12: Comportamento mediante análise da irradiação
Figura 13: Comportamento mediante análise da temperatura
Foram realizados testes diários após montagem e a rotina de medições ocorreu de 2
a 3 vezes ao dia com o intuito de acompanhar cada evolução. Desse modo, destacaram-se
alguns itens importantes para manutenção do controlador, principal aliado nesta fase, que
foram necessários ajustes personalizados para a bateria e placa (Tabela 3).
Parâmetro Ajuste
Over Volt Disc Desconexão de alta voltagem
Charg lmt Máxima voltagem
13
Over volt Rect Conexão de alta voltagem
Low V. Rect Conexão de baixa voltagem
Low V. Disc Desconexão de baixa voltagem
Discharg Lmt Voltagem mínima
Charge Máximo de carga que a bateria poderia atingir (%)
Discharge Mínimo de carga que a bateria poderia atingir (%)
Nominal Voltagem e Amperagem da bateria, modelo, corrente de carga e do
sistema normalmente.
Tabela 3: Parâmetros corrigidos no controlador.
3.3 Análise de resultados
Já em campo, coletamos informações do controlador de maneira a analisar sua carga
e descarga (Figura 14), vimos que a bateria sofreu forte influencias climáticas, no que diz
respeito a sua velocidade de carga, pois, como no sistema de baterias temos ao todo uma de
amperagem de 80A, era esperado que sua carga levasse um tempo para carregar por
completo, tendo em vista que a amperagem era alta e não é viável transferir uma quantidade
de corrente muito alta para as baterias de forma rápida, levou em torno de um dia para as
baterias carregarem por completo pela primeira vez. Estima-se que, ao gerenciar o Switch
com todos os aparelhos em funcionamento ideal, o carregamento de energia permaneceria
por 1 dia a 1 e meio. Contudo estão sendo feitos estudos sobre a real funcionalidade dos
equipamentos, detecção de sinal e expectativas mais precisas.
14
Figura 14: Dados em tempo real
3.4 Dificuldades e soluções
Durante a execução dos testes e monitoramento de energia, houveram alguns
detalhes a serem corrigidos e alguns ainda estão sendo trabalhados.
A princípio, foi mudado o controlador carga, para um que fornecesse mais
informações, o que exigiu mais conhecimento de parâmetros e configurações, com o intuito
de garantir maior credibilidade. Foi realizada uma análise do controlador, utilizando o cabo
conversor RS485 para USB, de forma a ter todas as informações do controlador no
computador. Para realizar a conexão do cabo RJ45, vindo do controlador, para o cabo
conversor foram feitas três tentativas de conexão. Inicialmente tentamos a conexão da figura
15, onde não foram obtidas as leituras, depois foi feita a conexão com base na figura 16, onde
também não conseguimos estabelecer a comunicação e por fim tentamos a conexão da figura
17, que também não nos retornou nenhum resultado de sucesso.
15
Figura 15
Figura 16
Figura 17
Além disso, foram detectados problemas com o clima, que faziam com que as
baterias carregassem mais lentamente do que o previsto em estimativas, contudo, após
checagem de parâmetro, configuração do tipo de bateria, obtivemos uma carga normalizada
das baterias até o presente momento, estipulando limiares para medição e funcionamento,
e vimos também que o pico de energia ocorre de acordo com a insolação nas placas, entre
16
13h até 15h, foi mudado em alguns momentos a posição do poste para analisar uma possível
alteração de eficiência, contudo, as medições praticamente se igualaram, decorrente do bom
funcionamento do módulo.
4. Sensoriamento
4.1 Descrição
Simultaneamente aos testes externos, como estava sendo feito o uso do controlador,
que é capaz de coletar informações para análise das baterias e de todo o sistema, estudamos
no laboratório uma maneira de agregar mais confiabilidade ao conjunto e está sendo
projetado um sensoriamento utilizando a placa Beaglebone Black (Figura 19), atrelada a um
sensor de gás (Figura 18) para garantir a segurança do ambiente, onde estavam os
equipamentos e o controlador exercendo o papel de sensor de tensão, corrente e
temperatura, embutidos no equipamento (Figura 2).
4.2 Especificação
4.2.1 Charger controller 20A
O controlador de carga de 20A, possui diversas funções que permitem a análise
sensorial. Ele nos fornece todas as informações de corrente, tensão e temperatura do
controlador. As informações podem ser lidas diretamente no software de monitoramento
fornecido pela EPSolar. A partir do uso de um shield RS485 para Arduino, é possível tratar os
dados e enviar para a nossa plataforma de monitoramento.
4.2.2 Sensor de Gás e Fumaça MQ-2
O Modulo Sensor de Gás e Fumaça MQ-2(Figura 18) possibilita a monitoração de
gases no ambiente, como gás de petróleo liquefeito, butano, propano, e tem uma
sensibilidade mais baixa para detectar também metano, etanol, e pode detectar outros tipos
de gases. Possui duas saídas, uma analógica que retorna o nível do gás no ambiente e outra
digital que indica a presença de gás.
17
Figura 18: Sensor de Gás MQ - 2
4.2.3 Beaglebone Black
Para termos um melhor processamento das informações captadas pelos sensores,
utilizamos em nossos testes a Beaglebone black (Figura 19). No momento estamos realizando
estudos sobre a montagem de um sistema que garanta a segurança do sistema, então, foi
testado previamente, sensores de tensão, temperatura, contudo, foram substituídos pelo
controlador mais moderno.
HARDWARE
● 512MB DDR3 RAM
● 4GB 8-bit eMMC on-board flash storage
● Gráficos 3D
● NEON floating-point accelerator
● 2 microcontroladores PRU 32-bit
CONECTIVIDADE:
● USB para carga e comunicação
● USB host
● Ethernet
● HDMI
● 2x 46 pin headers
18
SOFTWARE
A Beaglebone, possui diversas compatibilidades, como a IDE embarcada no
dispositivo e que pode ser acessada pelo navegador na porta 3000. Supondo que o IP da
Beaglebone seja “192.168.0.7”, é possível acessar esta IDE digitando no seu navegador
“http:/192.168.0.7:3000”.
Os Headers na lateral da placa são as portas de entrada e saída (GPIO, 65 no total),
que podem ser utilizadas para monitorar e controlar sensores, botões, módulos e outros
dispositivos. A alimentação externa do BeagleBone é feita por uma fonte de no máximo 5v.
Com o slot microSD é possível carregar uma imagem de um dos sistemas
operacionais disponíveis, e transferi-lo para a memória do BeagleBone. Desta forma, o
BeagleBone funciona como um computador, ligando a placa à um monitor utilizando o
conector microHDMI (resolução máxima de 1280 x 1024 pixels). É possível também, ligar um
teclado e um mouse USB ao Beaglebone.
A linguagem utilizada para desenvolver o protótipo, trata-se da BoneScript,
linguagem que se assemelha bastante com a usada no Arduino, onde é visto comando como
PinMode(),AnalogRead(), DigitalWrite(), entre outros.
Figura 19: Beaglebone
19
5. Redes
5.1 Descrição
O Hot-spot estabelece comunicação por meio de três equipamentos de rádio. Sendo
uma antena(1) principal, localizada em local pré-estabelecido, alto e de boa visibilidade, a
qual recebe o link de internet através de cabo de rede e o retransmite por meio de uma
conexão sem fio para uma segunda antena(2), a qual por sua vez retransmite o link recebido
por meio de conexão sem fio para um switch, por meio de cabo de rede, este switch realiza o
compartilhamento do link recebido pela segunda antena à uma terceira antena(3), que tem
como função disponibilizar acesso à internet para pessoas e dispositivos inseridos no
ambiente ao qual o hot-spot esteja posto.
5.2 Estrutura de Interconexão
5.2.1 NanoStation M5
(1) NanoStation NSM5, que opera na faixa de 5170 - 5875 MHz, com potência de
saída de 28 dBm e ganho de 16 dBi, transmitindo a uma distância superior a 15 Km com
capacidade de link de até 150 Mbps. Este equipamento é o ponto de conexão principal, a
partir deste link de internet estabelece a comunicação com o hot-spot dentro de sua área de
cobertura. o rádio deve ser fixado em local alto e de boa visibilidade, com relação a antena,
para uma melhor qualidade de sinal. A antena recebe o link de internet por meio de cabo de
rede (par trançado) e retransmite a conexão, para o hot-spot alvo, por meio de interface de
wireless.
Figura 20: NanoStation NSM5
20
5.2.2 PowerBeam
(2) PowerBeam M5-300, que opera na faixa de 5GHz, com potência de saída de 26
dBm e ganho de 22 dBi, transmitindo a uma distância superior a 20 Km com capacidade de
link de até 150 Mbps. Este equipamento permite que cada hot-spot estabeleça comunicação,
individualmente, como o ponto de conexão principal, por meio de interface wireless e,
retransmita o link de internet por cabo de rede (par trançado) para o switch instalado junto
ao hot-spot.
Figura 21: PowerBeam M5-300
5.2.3 NanoStation M2
(3) NanoStation NSM2, que opera na faixa de 2412 - 2462 MHz, com potência de
saída de 28 dBm e ganho de 11 dBi, transmitindo a uma distância superior a 13 Km com
capacidade de link de até 150 Mbps. Este equipamento tem por função disponibilizar acesso
à internet para pessoas e dispositivos inseridos no ambiente no qual o hot-spot esteja posto.
O rádio recebe o link de internet, pelo switch, por meio de cabo de rede (par trançado) e, o
retransmite por interface de rede wireless para o ambiente no qual está posto.
21
Figura 22: NanoStation M2
Espectro de Rede
Exemplificação em condenadas dos gráficos Azimuth e Elevation, nas posições
vertical e horizontal, do NanoStation(NSM5), NanoStation(NSM2) e PowerBeam(M5-300).
Fonte: www.ubnt.com/airmax
5.2.4 NanoStation (NSM5)
Figura 23: Espectro de Sinal
22
Figura 24 : Espectro de Sinal
5.2.5 NanoStation (NSM2)
Figura 25: Espectro de Sinal
23
Figura 26: Espectro de Sinal
5.2.6 PowerBeam (M5-300)
Figura 27 - Espectro de Sinal
24
Figura 28 - Espectro de Sinal
5.3 Topologia e configurações
A topologia de rede escolhida para ser aplicada, foi a ponto a ponto, pelo fato de
inicialmente, a níveis de testes e analises, termos que atender, isoladamente, a apenas um
hot-spot, pela alta capacidade e velocidade e pôr o ambiente ao qual os equipamentos estão
dispostos proporcionar linha de visada direta entre ambas as antenas. A antenas principal,
instalada na cobertura do IMD-CIVT e a segunda antenas, fixada junto ao poste, também
instalado na cobertura do IMD-CIVT, mas em níveis de altura diferentes. Ambas as antenas
operando na faixa de 5 GHz. Onde temos a antena principal definida como Access Point, com
SSID definido igualmente nas duas antenas, operando em conjunto nos padrões IEEE 802.11a
e IEEE 802.11n, em canal 11 e frequência de 40 MHz, com potência de saída em dBm ajustada
automaticamente e camada de criptografia de rede WPA2-AES. A segunda antena, que foi
instalada junto ao poste, está definida como estação, recebendo o mesmo SSID aplicado na
antena principal, operando no padrão IEEE 802.11a e IEEE 802.11n, em canal 11 e frequência
de 40 MHz, com potência de saída em dBm ajustada automaticamente e camada de
criptografia de rede WPA2-AES. A terceira antena, que tem por função disponibilizar acesso
à internet para as pessoas e dispositivos inseridos no ambiente no qual o hot-spot esteja
posto, opera na faixa de 2.4GHz (a faixa de frequência foi escolhida por ser a utilizada por
grande parte dos dispositivos móveis). Este equipamento está definido como Access Point,
25
com SSID e senha diferentes das antenas anteriores (um e dois), trabalha nos padrões IEEE
802.11b, IEEE 802.11g e IEEE 802.11n, com ajuste de canal automático e frequência de 20
MHz e camada de criptografia de rede WPA2-AES.
Embora a topologia de rede utilizada tenha sido a topologia ponto a ponto, foram
analisadas outras topologias, como proposta de aplicação em um número maior de hot-spots
instalados. Como exemplo, a topologia Mesh sem fios, pois na topologia Mesh, a comunicação
pode ser distribuída por vários hot-spots, criando rotas alternativas, evitado assim o
congestionamento da comunicação e, tornando o desempenho da rede muito superior.
5.4 Dificuldades e Soluções
Ocorreram problemas quanto colocação do hot-spot em campo para que fossem
realizados testes relacionados a comunicação entre as antenas. Inicialmente pensou-se em
fixá-lo na cobertura do prédio do Instituto Metrópole Digital (IMD-CIVT), por ser um ambiente
com espaços adequados para testes em distancias curtas (de 10 à 30 metros), pela maior
facilidade para instalação da infraestrutura de rede, já que poderia ser utilizada a estrutura
do próprio IMD-CIVT e por ser próximo aos professores e alunos envolvidos no projeto de
pesquisa. Contudo, a área a ser utilizada necessitou ser revista, pois no ambiente atual
existem alguns obstáculos, como, aparelhos de ar condicionados, paredes e telhados baixos
de leve inclinação. Como solução a estes problemas, foi-se proposto a colocação do hot-spot
numa outra parte da cobertura do IMD-CIVT e a instalação de uma haste de maior tamanho
(aproximadamente 2 metros), para que seja fixada o equipamento de rádio NanoStation
NSM5 para que seja estabelecia a comunicação com o hot-spot e realizados os testes e
analises de rede.