• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
UM ESTUDO PARA A IMPLANTAÇÃO DE UM MODELO DE GERÊNCIA DE NUVEM HÍBRIDA UTILIZANDO SOLUÇÕES DE CÓDIGO ABERTO
 

UM ESTUDO PARA A IMPLANTAÇÃO DE UM MODELO DE GERÊNCIA DE NUVEM HÍBRIDA UTILIZANDO SOLUÇÕES DE CÓDIGO ABERTO

on

  • 2,687 views

Projeto de pesquisa para conclusão de curso baseado no Openstack e da análise de outras soluções de nuvem IaaS.

Projeto de pesquisa para conclusão de curso baseado no Openstack e da análise de outras soluções de nuvem IaaS.

Statistics

Views

Total Views
2,687
Views on SlideShare
2,684
Embed Views
3

Actions

Likes
2
Downloads
59
Comments
0

1 Embed 3

http://www.linkedin.com 3

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    UM ESTUDO PARA A IMPLANTAÇÃO DE UM MODELO DE GERÊNCIA DE NUVEM HÍBRIDA UTILIZANDO SOLUÇÕES DE CÓDIGO ABERTO UM ESTUDO PARA A IMPLANTAÇÃO DE UM MODELO DE GERÊNCIA DE NUVEM HÍBRIDA UTILIZANDO SOLUÇÕES DE CÓDIGO ABERTO Presentation Transcript

    • UNIVERSIDADE DO VALE DO RIO DOS SINOS - UNISINOS UNIDADE ACADÊMICA DE GRADUAÇÃO CURSO DE SEGURANÇA DA INFORMAÇÃO MARCELO DIEDER UM ESTUDO PARA A IMPLANTAÇÃO DE UM MODELO DE GERÊNCIA PARA A INFRAESTRUTURA DE COMPUTAÇÃO NAS NUVENS UTILIZANDO SOLUÇÕES DE CÓDIGO ABERTO São Leopoldo 2012
    • MARCELO DIEDER UM ESTUDO PARA A IMPLANTAÇÃO DE UM MODELO DE GERÊNCIA PARA A INFRAESTRUTURA DE COMPUTAÇÃO NAS NUVENS UTILIZANDO SOLUÇÕES DE CÓDIGO ABERTO Trabalho de Conclusão de Curso apresentado como requisito parcial para a obtenção do título de Tecnólogo em Segurança da Informação na Universidade do Vale do Rio dos Sinos - UNISINOS Orientador: Prof. Ms. Jeferson Prevedello São Leopoldo 2012
    • Dedico totalmente este trabalho para a minha família, que me deu forças para conseguir superar minhas dificuldades e serenidade para continuar a trilhar pelos caminhos obscuros. Aos meus pais e à minha irmã, que desde meus primeiros momentos de vida me transmitiram ensinamentos e caráter de vida, tão importante nesta atual fase da minha vida. Agradeço muito à minha esposa e à minha filha, pelo apoio incondicional que me proporcionaram nos momentos difíceis e que, com simples sorrisos, conseguiam me motivar ainda mais em busca de melhores resultados.
    • AGRADECIMENTOS Primeiramente a Deus, por mostrar-me os melhores caminhos a seguir e à minha família que sempre me acolheu e me aconselhou durante a fase de estudos. Ao meu orientador Jeferson Prevedello, que soube me criticar construtivamente em minhas dúvidas e anseios. . Aos meus colegas de curso, que me possibilitaram a troca de conhecimentos durante todos estes anos de estudo. Ao pessoal das comunidades openstack e openstack-br, que estavam prontamente disponíveis para tirar dúvidas e trocar ideias. Por fim, gostaria de agradecer a todos aqueles que me ajudaram diretamente ou indiretamente no desenvolvimento deste trabalho.
    • "Nossas dúvidas são traidoras e nos fazem perder o que, com frequência, poderíamos ganhar, por simples medo de arriscar." (William Shakespeare)
    • RESUMO O conceito de Computação nas Nuvens é um grande salto tecnológico após o surgimento da Internet. Na necessidade de buscar soluções que possam reduzir custos e agregar mais segurança e desempenho para as aplicações, surge o modelo de entrega de serviços computacionais sob demanda. Por meio de uma pesquisa bibliográfica, este trabalho buscou entender os principais conceitos da computação nas nuvens, seus principais problemas e os limites impostos pela nova tecnologia. A pesquisa também abordou os sistemas de IaaS Eucalyptus e OpenStack, apresentando suas principais características e descrevendo o modelo de arquitetura de cada plataforma. Além disso, utilizando uma abordagem experimental, o sistema OpenStack foi implantando com o intuito de entender melhor o seu funcionamento e obter respostas quanto a seu nível de maturidade atual. A partir da implantação do sistema OpenStack, foi possível entender na prática seu funcionamento, revelando ser uma plataforma robusta e estável, e que pode ser utilizado para orquestrar uma infraestrutura heterogênea que possua um conjunto de diferentes sistemas e equipamentos. Este trabalho também poderá ser utilizado como base para futuros projetos de pesquisa, que buscam o desenvolvimento de uma solução para a computação nas nuvens ou mesmo para corporações que desejam executar seu próprio modelo de nuvem pública ou privada. Palavras-chave: computação nas nuvens, Openstack, serviços sob demanda.
    • ABSTRACT The concept of Computing in the Clouds is a great technological leap after the advent of the Internet. The need to seek solutions that can reduce costs and add more security and performance for applications, the model appears to deliver on- demand computing services. Through a bibliographical survey, this study sought to understand the key concepts of cloud computing, its main problems and the limits imposed by the new technology. The research also addressed the IaaS systems Eucalyptus and OpenStack, presenting their main characteristics and describe the architectural model of every platform. Furthermore, using an experimental approach, the OpenStack system was implemented in order to better understand their operation and get answers about their current maturity level. Upon deployment of the OpenStack, in practice it was possible to understand its operation, proving to be a robust and stable plataform and can be used to orchestrate a heterogeneous infrastructure that has a large set of different systems and equipment. This work may also be used as a basis for future research projects aimed at developing a solution to the cloud, or even for corporations that want to run their own model of public or private cloud. Keywords: cloud computing, openstack, on-demand services.
    • LISTA DE FIGURAS Figura 1 - Arquitetura do modelo de computação nas nuvens........................27 Figura 2 - Camadas da Computação nas Nuvens..........................................31 Figura 3 – Visão Global da Computação nas Nuvens. ...................................33 Figura 4 - Limites entre IaaS, PaaS, SaaS .....................................................37 Figura 5 - Pesquisa sobre Computação nas Nuvens......................................41 Figura 6 - Responsabilidades entre modelos computacionais da nuvem .......48 Figura 7 - Tipos de arquitetura de virtualização..............................................53 Figura 8 - Arquitetura principal do Eucalyptus. ...............................................64 Figura 9 - Arquitetura conceitual do Openstack..............................................67 Figura 10- Arquitetura de serviços do Openstack Compute (Nova)................69 Figura 11 - Arquitetura de rede do nova-network. ..........................................73 Figura 12 - Arquitetura do nova-volume..........................................................74 Figura 13 - Fluxograma do processo de decisão do nova-scheduler. ............76 Figura 14 - Exemplo de arquitetura do OpenStack Swift. ...............................78 Figura 15 - Exemplo de anel utilizado no OpenStack Swift. ...........................80 Figura 16 - Arquitetura lógica do OpenStack Glance......................................81 Figura 17 - Processo para criação de um serviço validado pelo Keystone.....86 Figura 18 - Tela de gerenciamento de instâncias do Horizon.........................88 Figura 19 - Estrutura externa do ambiente proposto. .....................................92 Figura 20 - Estrutura externa do ambiente proposto. .....................................93 Figura 21 - Gráfico do resultado da análise dos dados de rede. ....................96 Figura 22 - Gráfico de desempenho das operações de leitura e escrita.........98
    • LISTA DE QUADROS Quadro 1 - Comparativo de opções de infraestrutura em TI...........................28 Quadro 2 - Soluções para gerenciamento de ambientes IaaS. ......................59 Quadro 3 - Filtros para utilização no nova-scheduler. ....................................75 Quadro 4 - Estados de uma imagem no Glance.............................................82 Quadro 5 - Tipos de imagens suportados pelo Glance...................................83 Quadro 6 - Tipos de containers suportados pelo Glance................................84 Quadro 7 - Comparativo de características entre OpenStack e Eucalyptus. ..89 Quadro 8 - Requisitos dos servidores para a estrutura...................................91 Quadro 9 - Gráfico de desempenho das operações de leitura e escrita.........99
    • LISTA DE TABELAS Tabela 1 - Versões de lançamento do Openstack ..........................................66 Tabela 2 - Tipos de instâncias pré-definidas pelo EC2...................................77 Tabela 3 - Lista de serviços ativos e inativos do Nova. ..................................95 Tabela 4 - Tabela do resultado da análise dos dados de rede. ......................96 Tabela 5 - Valores de desempenho das operações de leitura e escrita. ........97
    • LISTA DE ABREVIATURAS E SIGLAS AMQP Advanced Message Queuing Protocol API Application Programming Interface ARP Address Resolution Protocol AWS Amazon Web Services CIFS Common Internet Filesystem CLC Cloud Controler SC Storage Controller CC Cluster Controller CMAAS Compliance as a Service CPU Central Processing Unit CSA Cloud Security Alliance DAS Direct Attached Storage DHCP Dynamic Host Configuration Protocol EBS Elastic Block Store EC2 Amazon Elastic Compute Cloud FC Fibre Channel GPL General Public License HP Hewlett-Packard ICMP Internet Control Message Protocol HTTP HyperText Transfer Protocol Secure I/O Input/Output IAAS Infrastructure as a Service IBM International Business Machines IDAAS Identity as a Service IDC International Data Corporation IP Internet Protocol ISCSI Internet Small Computer System Interface JSON Javascript Object Notation KVM Kernel-based Virtual Machine LAN Local Area Network LDAP Lightweight Directory Access Protocol LUN Logical Unit Number
    • 12 LVM Logical Volume Manager LXC Linux Containers MTBF Mean Time Betwenn Failures NAS Network Attached Storage NASA National Aeronautics and Space Administration NBR Normas Brasileiras de Regulação NC Node Controller NFS Network File System PAAS Platform as a Service PATA Parallel Technology Attachment PCI Payment Card Industry PCI DDS PCI Data Security Standard RAID Redundant Array of Independent Disks REST Representational State Transfer S3 Amazon Simple Storage Service SAAS Software as a Service SAN Storage Area Network SAS Serial Attached SCSI SAS 70 Statement on Auditing Standards No. 70 SATA Serial Advanced Technology Attachment SC Storage Controller SCSI Small Computer System Interface SPI SaaS PaaS IaaS SSH Secure Shell STAAS Storage as a Service TCP Transmission Control Protocol TCP/IP Transmission Control Protocol / Internet Protocol TI Tecnologia da Informação UML User Mode Linux VLAN Virtual Lan VM Virtual Machine VMM Virtual Machine Monitor VNC Virtual Network Computing
    • 13 VPN Virtual Private Network XFS High-Performance Journaling File System XML Extensible Markup Language
    • SUMÁRIO 1 INTRODUÇÃO .......................................................................................................18 1.1 DEFINIÇÃO DO PROBLEMA..............................................................................18 1.2 OBJETIVOS ........................................................................................................21 1.2.1 Objetivo Geral.................................................................................................21 1.2.2 Objetivos Específicos ....................................................................................21 1.3 JUSTIFICATIVA ..................................................................................................22 1.4 DELIMITAÇÃO DO TEMA...................................................................................23 2 FUNDAMENTAÇÃO TEÓRICA.............................................................................25 2.1 COMPUTAÇÃO NAS NUVENS ..........................................................................26 2.1.1 Características do Modelo Computacional em Nuvem...............................27 2.1.2 A Importância da Virtualização e o Armazenamento Centralizado............31 2.1.3 O Modelo Computacional da Computação nas Nuvens .............................32 2.1.4 Principais Conceitos......................................................................................33 2.1.5 Arquiteturas....................................................................................................35 2.1.5.1 Público...........................................................................................................35 2.1.5.2 Privado ..........................................................................................................35 2.1.5.3 Comunitário...................................................................................................36 2.1.5.4 Híbrido...........................................................................................................36 2.1.6 Tipos de Serviço.............................................................................................36 2.1.6.1 Infraestrutura como um Serviço ....................................................................38 2.1.6.2 Plataforma como um Serviço ........................................................................39 2.1.6.3 Software como um Serviço............................................................................39 2.2 A SEGURANÇA E OS LIMITES DA COMPUTAÇÃO NAS NUVENS .................40 2.2.1 Principais Preocupações...............................................................................41 2.2.2 Limites da nuvem ...........................................................................................42 2.2.2.1 Confidencialidade das informações...............................................................43 2.2.2.2 Disponibilidade de serviços ...........................................................................43 2.2.2.3 Tipos de aplicações.......................................................................................44 2.2.2.4 Conformidade com a legislação vigente........................................................44 2.2.2.5 Multi-Inquilino ................................................................................................45 2.2.2.6 Dependência do fornecedor ..........................................................................46 2.2.3 Cloud Security Alliance .................................................................................46
    • 15 2.3 VIRTUALIZAÇÃO................................................................................................49 2.3.1 Vantagens .......................................................................................................50 2.3.2 Desvantagens .................................................................................................50 2.3.3 Virtual Machine Monitor.................................................................................51 2.3.4 Soluções de Virtualização .............................................................................53 2.3.4.1 Kernel-based Virtual Machine .......................................................................54 2.3.4.2 Qemu.............................................................................................................54 2.3.4.3 Xen................................................................................................................54 2.3.4.4 Vmware ESX.................................................................................................55 2.3.4.5 Virtualbox ......................................................................................................55 2.4 O ARMAZENAMENTO DE DADOS ....................................................................55 2.4.1 Direct Attached Storage.................................................................................56 2.4.2 Network Attached Storage.............................................................................56 2.4.3 Storage Area Network....................................................................................56 3 SOLUÇÃO PARA GERÊNCIA DA INFRAESTRUTURA DA NUVEM ..................58 3.1 ORQUESTAR O AMBIENTE DA NUVEM...........................................................58 3.2 SOLUÇÕES DE IAAS EXISTENTES ..................................................................58 3.2.1 Amazon Web Services ...................................................................................59 3.2.2 Nimbus ............................................................................................................60 3.2.3 OpenNebula ....................................................................................................60 3.2.4 Eucalyptus ......................................................................................................61 3.2.5 OpenStack.......................................................................................................61 3.2.6 Análise Parcial das Soluções........................................................................62 3.3 EUCALYPTUS ....................................................................................................63 3.3.1 Principais Componentes ...............................................................................63 3.3.1.1 Cloud Controller (CLC)..................................................................................64 3.3.1.2 Walrus ...........................................................................................................64 3.3.1.3 Cluster Controller (CC)..................................................................................64 3.3.1.4 Storage Controller (SC).................................................................................65 3.3.1.5 Node Controller (NC).....................................................................................65 3.3.1.6 VMware Broker..............................................................................................65 3.3.1.7 Euca2ools......................................................................................................65 3.4 OPENSTACK ......................................................................................................66
    • 16 3.4.1 Visão Global....................................................................................................67 3.4.2 Openstack Compute (Nova) ..........................................................................68 3.4.2.1 API Server (nova-api)....................................................................................70 3.4.2.2 Message Queue (Rabbit MQ Server) ............................................................71 3.4.2.3 Compute Worker (nova-compute) .................................................................71 3.4.2.4 Network Controller (nova-network)................................................................71 3.4.2.5 Volume Workers (nova-volume)....................................................................73 3.4.2.6 Nova Objectstore (nova-objectstore).............................................................74 3.4.2.7 Scheduler (nova-scheduler) ..........................................................................74 3.4.2.8 Tipos de Instâncias (Flavors) ........................................................................76 3.4.3 Openstack Storage Infrastructure (Swift).....................................................77 3.4.3.1 Swift Proxy Server.........................................................................................78 3.4.3.2 Swift Object Server........................................................................................78 3.4.3.3 Swift Container Server...................................................................................79 3.4.3.4 Swift Account Server .....................................................................................79 3.4.3.5 The Ring........................................................................................................79 3.4.4 Openstack Imaging Service (Glance) ...........................................................81 3.4.4.1 Glance-api.....................................................................................................82 3.4.4.2 Glance-registry ..............................................................................................83 3.4.4.2 Formato de Discos e Containers ...................................................................83 3.4.5 OpenStack Identity Service (Keystone)........................................................84 3.4.5.1 Base de Dados..............................................................................................86 3.4.6 Openstack Administrative Web-Interface (Horizon)....................................86 3.5 ANÁLISE DO EUCALYPTUS E OPENSTACK....................................................88 4 PROJETO PRÁTICO E RESULTADOS OBTIDOS...............................................90 4.1 AMBIENTE DA PROPOSTA DE TRABALHO.....................................................90 4.1.1 Requisitos da infraestrutura..........................................................................91 4.1.2 Arquitetura do ambiente................................................................................91 4.1.3 Processo de Instalação..................................................................................93 4.2 COLETA DE DADOS DO AMBIENTE.................................................................94 4.2.1 Testes de Latência de Rede X Testes de Troca de Tráfego........................94 4.2.2 Testes de Leitura e Gravação de Dados.......................................................94 4.2.3 Simulação de falhas nos serviços do Nova .................................................95
    • 17 4.3 ANÁLISE DOS DADOS OBTIDOS......................................................................95 4.3.1 Da latência e desempenho da rede...............................................................95 4.3.2 Da latência e velocidade das operações de disco ......................................96 4.3.3 Da análise da disponibilidade dos componentes........................................98 5 CONCLUSÃO ......................................................................................................100 REFERÊNCIAS.......................................................................................................103 APÊNDICE A ..........................................................................................................111
    • 18 1 INTRODUÇÃO Computação nas Nuvens é um dos principais assuntos no atual momento da Tecnologia da Informação. A Computação nas Nuvens traz consigo conceitos de entrega de tecnologia como um serviço computacional, da mesma forma que serviços como água e a eletricidade, entregando-os sob demanda. Computação nas Nuvens não é uma nova tecnologia ou um novo sistema computacional, é uma nova maneira de utilização de recursos computacionais de forma distribuída e descentralizada, utilizando como meio de transporte, principalmente, a Internet. Pode-se utilizar a nuvem para o armazenamento e processamento de informações, de forma escalável e sob a demanda necessária, ou seja, conforme aumenta a necessidade de processamento e cresce o volume de informações, pode-se dinamicamente alocar mais recursos computacionais, conforme necessário. Observa-se, desta maneira, que ao invés de investir-se em uma infraestrutura computacional completa, repleta de ativos computacionais, pode-se focar em investimento de serviços. Neste caso, o custo é apenas dos recursos utilizados, além de reduzir as despesas com infraestrutura. Nem sempre a utilização de serviços sob demanda pode ser vantajoso, isso pode depender do tipo de aplicação e da demanda necessária para atender a determinados requisitos. Também é importante salientar que na nuvem não se sabe onde está a informação, ou onde ela será processada, mas é essencial que a informação esteja íntegra e sempre disponível. Este trabalho está dividido em cinco capítulos. No primeiro capítulo será realizada a introdução do tema a ser abordado. No capítulo dois, é apresentada uma fundamentação teórica dos assuntos relacionados. No capítulo três, são descritas as soluções de gerenciamento da nuvem. No capítulo quatro, será descrito a implantação do projeto. E por fim, no capítulo cinco, será realizada a conclusão do tema. 1.1 DEFINIÇÃO DO PROBLEMA Com o avanço do conceito de tecnologia em nuvem, diversas soluções surgiram para orquestrar diferentes tipos de plataformas e serviços, mas sem que
    • 19 houvesse uma definição exata de um modelo estruturado que garantisse a padronização desta nova arquitetura. De acordo com pesquisa realizada em 2011 com 500 organizações, encomendada pela Symantec Corporation sobre a situação da Cloud Computing na América Latina, SYMANTEC (2011), foi possível apontar quatro principais preocupações que as organizações possuem quanto à utilização da Cloud, conforme é possível observar a seguir:  segurança das Informações;  falta de experiência de equipes de TI;  diferentes tipos de soluções e ausência de testes efetivos na nuvem;  retorno sobre investimento abaixo do esperado. É possível observar que a pesquisa apresenta dados concretos sobre algumas das dificuldades das corporações utilizarem a nova tecnologia, principalmente pelas dúvidas quanto à segurança dos dados e pela falta de experiência de equipes, juntamente com os diferentes tipos de tecnologias para enviar os dados para a nuvem. O caminho para a utilização de Cloud Computing passa pelos conceitos de virtualização e de armazenamento de informação centralizado, que são essenciais para o desenvolvimento da plataforma descentralizada. Atualmente, existem diversas soluções que podem realizar a virtualização de máquinas, assim como também existem diversos tipos de sistemas de armazenamento disponíveis. As grandes dificuldades estão em garantir a integração entre os diferentes tipos de sistemas, em efetuar o gerenciamento do ambiente heterogêneo e, também, de possibilitar a migração dos dados entre eles de forma rápida e funcional. Além disso, a preocupação com a segurança dos dados na nuvem é outro fator impeditivo para várias corporações, ao analisarem o risco na utilização de suas informações na nuvem. Em um ambiente de nuvem que fornece infraestrutura, como máquinas virtuais e espaço de alocação de dados, toda essa gerência é executada pelo chamado Cloud Controler, o controlador de recursos da nuvem1 . Atualmente existem inúmeras plataformas controladoras, sejam elas do modelo de código aberto ou
    • 20 mesma de código fechado. O grande esforço destas plataformas é garantir a interoperabilidade com os diferentes tipos de hypervisors2 , storages3 , redes de comunicação e as API (Application Programming Interface)4 de integração, de modo que as corporações possam percorrer pelos diferentes tipos de tecnologias de forma rápida e facilitada. No cenário atual, podemos citar com destaque as operações realizadas pelos fornecedores Amazon5 e Rackspace6 , duas das principais empresas mundiais que providenciam serviço de infraestrutura na nuvem. Das soluções existentes, que possibilitam que empresas públicas e privadas tenham sua própria nuvem, pode-se citar inúmeras aplicações, sejam elas de código fechado ou aberto. A Citrix Systems oferece uma solução proprietária de gerenciamento de infraestrutura chamado CloudStack, que apresenta integração com múltiplos tipos de sistemas. A Vmware Inc, possui uma solução proprietária conhecida como vCloud, porém gerencia apenas suas próprias aplicações de virtualização. Entre as soluções de código aberto, também é possível apresentar várias aplicações, dentre as quais são possíveis citar o OpenNebula, Nimbus, OpenStack e o Eucalyptus (disponibiliza versão aberta e proprietária). Entretanto, apesar da grande oferta de aplicações existentes, vários padrões foram desenvolvidos, dificultando a comunicação harmoniosa entre os diferentes tipos de sistemas. As soluções de plataforma fechada tendem a ditar “as regras do jogo”, buscando sempre os interesses do próprio negócio. Do contrário, as soluções de código aberto buscam atender aos interesses de todos os envolvidos no projeto, aumentando, consequentemente, a interoperabilidade entre diferentes sistemas, e atribuindo o controle do projeto para todos os seus participantes. A nuvem é um ambiente complexo e heterogêneo, e necessita de colaboração mútua entre todos os personagens deste sistema. Diante deste cenário, é possível delinear a definição do problema: É possível que uma plataforma de software aberto, no esforço de seus colaboradores mundiais, consiga apresentar uma solução segura e eficaz, que possa controlar e gerenciar a infraestrutura de diferentes soluções de virtualização e de armazenamento de forma 1 Conhecido também como IaaS ( Infrastructure as a Service) – Tipo de serviço oferecido na nuvem. 2 Hypervisor – Camada de software que realiza a virtualização de máquinas virtuais. 3 Storage – Equipamento de armazenamento de dados centralizado. 4 API – Interface para comunicação entre vários tipos de sistemas. 5 Amazon – Empresa multinacional de comercio eletrônico com base nos EUA.
    • 21 a oferecer serviços de IaaS, além de agregar maior segurança para a computação nas nuvens? 1.2 OBJETIVOS Serão descritos a seguir, os objetivos geral e específicos deste trabalho, de modo a esclarecer o escopo do trabalho. 1.2.1 Objetivo Geral Este trabalho terá como objetivo geral a descrição das terminologias que envolvem a Computação nas Nuvens, a apresentação dos resultados qualitativos obtidos a partir do comparativo com entre o OpenStack e o Eucalyptus, e da implantação de um ambiente da nuvem utilizando o projeto de código aberto Openstack. 1.2.2 Objetivos Específicos - Apresentar e descrever os modelos e a arquitetura que envolve a computação nas nuvens, evidenciando os principais benefícios de sua utilização e seus principais riscos. - Identificar os componentes que formam o projeto Openstack, apresentando detalhadamente quais são suas responsabilidades e atribuições, e quais os níveis de maturidade destes componentes. - Apresentar os resultados obtidos da implantação de uma infraestrutura de nuvem, utilizando o projeto Openstack, salientando, também, questões de desempenho, de confiabilidade, integridade e disponibilidade. - Através de pesquisas, apresentar a descrição dos componentes da aplicação Eucalyptus e uma tabela comparativa com as principais funcionalidades, capacidades e limites dos projetos Openstack e Eucalyptus. 6 Rackspace – Empresa multinacional provedora de serviços de TI, com base nos EUA.
    • 22 1.3 JUSTIFICATIVA O poder de cálculo dos atuais processadores, associado a grande evolução das mídias de armazenamento de informações, despontou a tecnologia de virtualização, possibilitando o aproveitando de recursos ociosos, reduzindo custos de infraestrutura, além de aumentar a disponibilidade dos sistemas e garantir aumentos de produtividade. A partir da propulsão da virtualização, com seus múltiplos hypervisors e de diferentes fabricantes, emerge a necessidade de um gerenciador central que tivesse o papel de integrar diferentes soluções; surgindo, assim, a computação nas nuvens. De acordo com Velte Ant; Velte Tob et al (2011,p.3), a computação em nuvem (Cloud Computing) está em toda parte. Abra qualquer revista de tecnologia ou visite qualquer site ou blog e certamente você verá alguma matéria sobre cloud computing. O único problema é que nem todos concordam com o que isso significa. Pergunte a dez profissionais diferentes o que é cloud computing e você obterá dez respostas distintas. Segundo a definição sobre nuvem de SCHUBERT et al (2010,p.8, tradução nossa), “a nuvem é uma execução elástica de recursos envolvendo múltiplos interessados e que provêm um serviço medido através de múltiplas granularidades para um nível de serviço adequado.” Existem diversos trabalhos publicados com o propósito de explicar a conceituação da computação nas nuvens, exaltando as principais características e evidenciando os problemas existentes da utilização de uma estrutura na nuvem. A proposta de Miranda et al. (2011), consiste em realizar o compartilhamento e estudo de grandes volumes de dados biológicos, utilizando processamento paralelo de uma Cloud, porém, não foca na descrição de uma solução para o gerenciamento do ambiente. Já o artigo de Nurmi et al. (2009) realiza a descrição da solução open- source Eucalyptus, apresentando a conceituação da Cloud e demonstrando a arquitetura interna do sistema, mas não traça um comparativo com demais soluções. Sotomayor et al. (2009), procura realizar um comparativo entre as principais soluções de administração do ambiente de Cloud Computing, destacando soluções como Amazon EC2, Nimbus, Eucalyptus, OpenNebula, entre outros, mas seu estudo não aprofunda em questões internas de cada aplicação. O trabalho de Delgado (2010) descreve detalhadamente a conceituação da nuvem, apresenta o Eucalyptus,
    • 23 e demonstra testes de desempenho realizados no ambiente controlado por ele, entretanto seus testes são focados, em sua maioria, nos sistemas de virtualização e não na plataforma da nuvem. O critério para a escolha pela implantação da solução Openstack ocorreu, pois não foram localizados trabalhos acadêmicos com comparativos entre o OpenStack e outras ferramentas de gerência da infraestrutura da nuvem. Além disso, a comparação com o Eucalyptus ocorrerá por ele ser uma plataforma estável e totalmente compatível com os serviços de nuvem oferecidos pela Amazon (Eucalyptus Systems, 2012a). Academicamente, o termo Cloud Computing é tema de diversos trabalhos, no entanto, também existem carências de trabalhos com foco no desenvolvimento e apresentação de soluções que possam gerenciar um ambiente complexo e heterogêneo como a nuvem. Enquanto a virtualização assume sua importância nos pilares da nuvem, existe, também, a necessidade de uma solução neutra, sem vínculos comerciais, capaz de gerenciar ambientes heterogêneos na nuvem e ser utilizada por pequenas, médias e grandes corporações. Dentro desta realidade, este trabalho justifica-se pela necessidade de um estudo que possa expor de uma forma clara, as definições sobre cloud computing e que relate como o projeto Openstack pode ajudar a viabilizar infraestrutura de nuvens públicas e privadas. 1.4 DELIMITAÇÃO DO TEMA Este estudo irá focar nas terminologias envolvendo a computação em nuvem, apresentando e descrevendo seus principais conceitos. Também apresentará o projeto Openstack, circunstanciando seus componentes e sua arquitetura de comunicação e também apresentará um análise comparativa entre as soluções OpenStack e Eucalyptus. A partir de um piloto prático, este trabalho irá realizar a instalação dos componentes Nova e Glance do OpenStack, irá apresentar a arquitetura do ambiente implantado e descreverá os testes realizados nos componentes. Ao final, a partir da coleta de dados, disponibilizará resultados qualitativos e quantitativos da solução implantada. Este trabalho não irá focar na integração com equipamentos de armazenamento centralizados, na implantação prática da aplicação Eucalyptus e
    • 24 durante a implantação do projeto dará ênfase apenas ao emulador QEMU, não utilizando demais sistemas de virtualização.
    • 25 2 FUNDAMENTAÇÃO TEÓRICA Este capítulo descreverá a conceituação de Computação nas Nuvens, apresentando suas principais características, modelos de arquiteturas, suas limitações, informando, também, suas principais vantagens e desvantagens, salientando no decorrer do texto, como ocorreu a evolução natural deste modelo computacional. O capítulo também apresentará a definição de virtualização e armazenamento de dados centralizados, e como eles estão ligados diretamente com a computação nas nuvens. Para a elaboração deste trabalho realizou-se o levantamento bibliográfico por meio de livros e artigos científicos que abordam sobre o tema apresentado no trabalho, além de sites de soluções utilizadas para a computação nas nuvens e que são reconhecidas na sua área de atuação. A elaboração dessa etapa foi fundamental para oferecer sustentação à pesquisa experimental realizada para a conclusão deste estudo. Ander-Egg (1978, apud Lakatos; Marconi, 2002, p. 15), afirma que a pesquisa é caracterizada por “um procedimento reflexivo sistemático, controlado e crítico, que permite descobrir novos fatos ou dados, relações ou leis, em qualquer campo do conhecimento”. Lakatos e Marconi (2002) ainda acrescentam que a pesquisa é considerada um caminho em busca do descobrimento da realidade e de verdades parciais, e, devido a isto, torna-se necessário um tratamento científico. A metodologia escolhida para a elaboração deste trabalho monográfico foi de pesquisa bibliográfica e experimental. A pesquisa bibliográfica, de acordo com Manzo (1971, apud Lakatos; Marconi, 2002, p. 71), “oferece meios para definir, resolver, não somente problemas conhecidos, como também explorar novas áreas onde os problemas não se cristalizam suficientemente” Trujillo (1974, apud Lakatos; Marconi, 2002, p. 71) complementa esta afirmação quando diz que a pesquisa bibliográfica “não é mera repetição do que já foi dito ou escrito sobre certo assunto, mas propicia o exame de um tema sob novo enfoque ou abordagem, chegando a conclusões inovadoras”.
    • 26 2.1 COMPUTAÇÃO NAS NUVENS Computação nas Nuvens, ou Cloud Computing é um novo modelo computacional que busca principalmente a redução de custos e o aumento de produtividade. A definição de Velte Ant; Velte Tob et al (2011,p.3) sobre cloud é que “a função da computação em nuvem (cloud computing) é cortar custos operacionais e o mais importante, permitir que departamentos de TI se concentrem em projetos estratégicos em vez de manter o data center funcionando”. O futuro da Cloud Computing pode ser comparado com a história da energia elétrica. Segundo Miller (2008, p.8, tradução nossa), O surgimento da computação em nuvem é o equivalente à revolução da energia elétrica do século passado. Antes do episódio de utilitários elétricos, cada fazenda e empresa de negócios produzia sua própria eletricidade a partir de geradores autônomos. Após a criação da rede elétrica, fazendas e empresas desativaram seus geradores e a energia elétrica foi comprada dos serviços públicos a um preço muito menor (e com confiabilidade muito maior) do que poderiam produzir por conta própria. Olhe para o mesmo tipo de revolução que ocorre com a computação em nuvem. De acordo com a definição do Nist7 (2011, p.2, tradução nossa), Computação nas Nuvens é, um modelo para permitir a onipresença, conveniente, o acesso à rede sob demanda para um pool compartilhado de recursos computacionais configuráveis (por exemplo, redes, servidores, armazenamento, aplicativos e serviços) que podem ser rapidamente fornecidos e liberados com o esforço de gerenciamento mínimo ou interação com o provedor de serviço. A arquitetura computacional do modelo da Cloud Computing evoluiu ao longo dos anos, a partir de outros modelos computacionais existentes, como o modelo cliente-servidor, o modelo peer-to-peer 8 , o modelo computacional distribuído, e o modelo grid de trabalho em grupo. Miller (2008) A nuvem utiliza-se de características de todos os modelos citados anteriormente, mas assemelha-se principalmente ao modelo computacional de Sistemas Distribuídos, onde várias máquinas trabalham em conjunto. Segundo Tanenbaum (1995, p.2, tradução nossa), “um sistema distribuído é uma coleção de 7 NIST - U.S. National Institute of Standards and Technology 8 Peer-to-Peer – Tipo de arquitetura de um sistema distribuído.
    • 27 computadores independentes, que aparecem para um usuário de um sistema como um único computador”. A figura 1, abaixo apresentada, ilustra o modelo computacional da Cloud Computing. Figura 1 - Arquitetura do modelo de computação nas nuvens Fonte: Editado pelo autor com base em Miller (2008, p. 16) Conforme Miller (2008, p. 16, tradução nossa), usuários individuais conectam na nuvem a partir de seus próprios computadores pessoais ou aparelhos portáteis, através da Internet. Para estes usuários individuais, a nuvem é vista como uma única aplicação, documento ou dispositivo. O hardware na nuvem (e do sistema operacional que gerencia as conexões de hardware) é invisível. 2.1.1 Características do Modelo Computacional em Nuvem A utilização do módulo computacional em nuvem, é conduzido pelas corporações em sua grande maioria, quando o objetivo principal é a redução de custos com infraestrutura. Entretanto, a cloud possibilita que corporações, ou até mesmo usuários finais, possam se beneficiar de outras características positivas que este modelo proporciona. Miller (2008, p. 24, tradução nossa) cita diversas vantagens da Cloud Computing:
    • 28  baixo custo com a aquisição de computadores para usuários;  aumento de desempenho;  baixo custo com infraestrutura de Tecnologia da Informação;  menor custo para manutenções de hardware e software;  menor custo aquisição de software;  atualização instantânea de sistemas;  aumento de poder de processamento;  capacidade de armazenamento ilimitada;  aumento de segurança no armazenamento de informações;  Aumento de compatibilidade entre sistemas distintos. As características citadas são vantagens que usuários finais ou corporações podem usufruir, não só reduzindo o custo, como também agregando maior qualidade aos serviços utilizados da TI. De acordo com o quadro de Reese (2009) apresentado a seguir, é possível observar o comparativo qualitativo entre uma solução em nuvem e duas opções comumente utilizadas pelas corporações para manter sua infraestrutura de TI. A primeira e mais clássica, é a utilização de uma infraestrutura interna onde a própria corporação é responsável por manter o capital físico e o capital humano. A segunda opção é a utilização de um serviço terceirizado, onde previamente existe um acordo mútuo entre a empresa contratante e a empresa contratada, de forma que possam delimitar as atribuições de cada um. A empresa terceirizada é responsável por manter toda a infraestrutura física, inclusive os serviços por ela prestados. Por fim, é ilustrada a utilização de serviços na nuvem, onde claramente se pode observar uma mescla de vantagens entre a opção de “TI Interna” e “Serviços Terceirizados”. Quadro 1 - Comparativo de opções de infraestrutura em TI TI Interna Serviços Tercerizados Computação nas Nuvens Investimento de Capital Significante Moderado Insignificante Despesas Moderado Significante Baseado na utilização Tempo de Provisionamento Significante Moderado Nenhum Flexibilidade Limitado Moderado Flexível Requisitos de Experiência Equipe Significante Limitado Moderado Confiança Varia Alto Moderado para Alto Fonte: Editado pelo autor com base em Reese (2009, p. 12)
    • 29 Ao mesmo tempo em que a Computação nas Nuvens pode reduzir o investimento de capital inicial para novos projetos de TI, diminui-se o tempo de provisionamento para novas instalações e aumenta-se a flexibilidade da infraestrutura de TI. Na opção pela nuvem, também é possível observar a necessidade de manter-se uma equipe de TI com experiência para que seja possível a integração entre sistemas internos e os sistemas alocados fora da empresa. Quanto à confiança da utilização dos serviços na nuvem, o que pode se observar é um acréscimo de segurança da infraestrutura, afinal provedores de soluções em nuvem utilizam de uma forma geral equipamentos redundantes e equipes especializadas e dedicadas em regime de tempo de 24x7x365. Além disso, operam de acordo com normatizações de segurança tais como a Statement on Auditing Standards Nº. 70 (SAS 70) 9 , Payment Card Industry - Data Security Standard (PCI DSS) 10 e a ISO IEC 27001 11 . Segundo Reese (2009, p. 9, tradução nossa), a nuvem necessariamente precisa ter um Mean Time Between Failures (MTBF)12 maior que uma estrutura interna, um desafio fundamental para qualquer sistema que exige longa vida de nós em uma infraestrutura de nuvem, é o fato básico de que o tempo médio entre falhas (MTBF) de um servidor virtual é necessariamente menor do que para o hardware subjacente. Desta maneira, pressupõe-se que uma infraestrutura na Cloud, terá um MTBF sempre maior que uma estrutura interna, afinal ela possui uma estrutura grande o suficiente para reduzir o número de falhas em equipamentos por meio da utilização de equipamentos redundantes e trabalhando cooperativamente. Velte Ant; Velte Tob et al. (2011, p. 30), também observa que a cloud computing pode oferecer diversos benefícios. Ele cita a escalabilidade, prevendo um crescimento futuro; a simplicidade do ambiente, permitindo que novos ambientes de infraestrutura estejam disponíveis de imediato; o aumento na qualidade dos serviços, afinal os fornecedores são qualificados para a realização de suas tarefas, e o 9 SAS 70 - Certificação que visa o controle e utilização de melhores práticas para empresas de prestação de serviços. http://sas70.com/sas70_overview.html 10 PCI DSS – Padrão de segurança de dados do setor de cartões de pagamento. https://www.pcisecuritystandards.org 11 ISO/IEC 27001 - Norma padrão para um sistema de gestão da segurança da informação. http://www.iso27001security.com/html/27001.html
    • 30 aumento de segurança das soluções utilizadas, na medida em que os fornecedores possuem políticas de privacidade rigorosas que garantem, possivelmente, mais segurança do que na própria TI local. Apesar dos benefícios que ambientes da nuvem podem proporcionar, nem tudo é vantajoso. Além das vantagens, Miller (2008, p. 24, tradução nossa) também cita algumas desvantagens na sua utilização:  necessidade constante de conexão à internet;  desempenho ruim com conexões de internet lenta;  mesmo em conexões rápidas, algumas aplicações podem ser mais lentas, quando comparadas com uma execução em um computador local;  limitações de determinados tipos de aplicações;  insegurança quanto à confidencialidade de informações;  indisponibilidade dos dados na eventual falha de um provedor de serviços na nuvem. A nuvem pode não ser a solução ideal para determinado perfil de empresa ou usuário. Conforme o comparativo de Reese apresentando anteriormente, os custos com a Cloud podem ser, inclusive, maiores se comparado a uma infraestrutura interna. A partir destas definições, as desvantagens citadas por Miller, como a incerteza na confidencialidade dos dados, podem inibir a ascensão da Cloud. Entretanto, as desvantagens da utilização desta nova arquitetura não devem interromper o seu crescimento, de acordo com pesquisas realizadas. Segundo estudo realizado pelo IDC (2010)13 , a previsão de crescimento da nuvem será de 27% por ano, entre 2009 até 2014. As corporações que pretendem fornecer serviços na nuvem, precisarão se posicionar de uma forma agressiva até o ano de 2013, para que não fiquem de fora do mercado. 12 MTBF – Cálculo utilizado para verificar o período médio entre falhas de um determinado dispositivo. 13 International Data Corporation – Empresa que realiza pesquisas de mercado. http://www.idc.com
    • 31 2.1.2 A Importância da Virtualização e o Armazenamento Centralizado A nuvem surgiu a partir do desenvolvimento e amadurecimento de soluções como a virtualização e o armazenamento centralizado. A tecnologia de virtualização permite que um hardware físico possa ser utilizado para instalação de diversas máquinas virtuais. A tecnologia de armazenamento centralizado permite unificar todas as informações em redes de armazenamento, simplificando a administração e aumentando a flexibilidade para a alocação de dados. É possível analisar na figura a seguir, que a nuvem está apoiada sob ambientes de virtualização e de armazenamento centralizado, ainda que a utilização destas soluções não seja obrigatória. Figura 2 - Camadas da Computação nas Nuvens Fonte: Editado pelo autor com base em IBM (2011) A virtualização é um dos pilares da Computação nas Nuvens, afinal ela possibilita uma melhor utilização de recursos computacionais, por meio da criação de diversos ambientes virtuais em máquinas físicas. Com a técnica da virtualização, é possível executar diversos sistemas operacionais de diferentes fabricantes em um mesmo servidor físico. Isso garante o aproveitamento máximo da utilização de processamento, memória e armazenamento de servidores, diminui
    • 32 consideravelmente o tempo com o gerenciamento e instalação de novos sistemas, além de reduzir custos com a administração do ambiente tecnológico e da aquisição de equipamentos físicos. O armazenamento de dados é um item indispensável para a Cloud Computing. É neste pilar que se situam as maiores dúvidas quanto a segurança e disponibilidade de dados. Na nuvem, todos os dados estão armazenados em diferentes locais, garantindo, assim, que as informações possam ser acessadas a qualquer momento e de qualquer lugar. Os dados podem estar alocados em diferentes tipos de sistemas de armazenamento, sejam eles equipamentos dedicados como storages, servidores, ou redes de armazenamento conhecidos como SAN (Storage Area Network). Um sistema robusto de gerenciamento é necessário para garantir a disponibilidade e o controle adequado das informações. 2.1.3 O Modelo Computacional da Computação nas Nuvens O modelo computacional da computação nas nuvens está dividido em conceitos, tipos de serviços e tipos de arquitetura. Este modelo computacional é essencial para o entendimento de como tudo funciona e, naturalmente, vem se adaptando aos novos conceitos, funcionalidades e arquiteturas. De acordo com MELL; GRANCE (2008, apud Sosinsky, 2011, p. 63), a nuvem é classificada em quatro tipos de arquiteturas, três modelos de serviço e, também, cinco principais conceitos sobre o funcionamento da cloud. Esta definição, criada originalmente pelo NIST, define as arquiteturas da nuvem em modelo comunitário, híbrido, privado e público. Também classifica os tipos de serviço em IaaS (Infrastructure as a Service), PaaS (Platform as a Service) e SaaS (Software as a Service). Por fim, define os cinco conceitos principais como conjunto de recursos, acesso amplo à rede, serviço medido, serviço sob demanda e rápida elasticidade. Conforme a figura apresentada a seguir, é possível observar a classificação acima descrita.
    • 33 Figura 3 – Visão Global da Computação nas Nuvens. Fonte: Editado pelo autor com base em Sosinsky (2011). 2.1.4 Principais Conceitos Com base no descritivo apresentado por Sosinsky e definido pelo NIST, é possível descrever os conceitos da Computação nas Nuvens.  Pool de Recursos: o Pool de Recursos está associado à quantidade de recursos computacionais que estarão disponíveis para os usuários finais, como a quantidade de processamento, memória e espaço de armazenamento. Com a definição da quantidade de recursos disponíveis, pode-se definir quanto será destinado para cada situação, e quando serão compartilhados. Os recursos podem ser compartilhados entre diversos usuários ao mesmo tempo, modo conhecido como multi-inquilino. Além disso, estes recursos podem estar geograficamente espalhados, porém de forma transparente para os usuários finais. Por exemplo, se pode definir um Pool de Recursos para um determinado grupo de usuários domésticos e outro para usuários corporativos. Sosinsky (2011, p. 63)  Serviços Sob Demanda: conhecido também como “on-demand”, o conceito de serviço sob demanda define como serão utilizados os
    • 34 serviços da nuvem. Assim como ocorre com outros serviços sob demanda, como o consumo de água e eletricidade, os serviços tecnológicos da cloud são utilizados conforme a necessidade, e são alocados dinamicamente, de acordo com o crescimento da demanda. Dessa forma, o custo total é a soma de todos os recursos utilizados em determinado período. Isto possibilita que aplicações cresçam dinamicamente, alocando automaticamente mais recursos sem que seja necessário mudanças na infraestrutura local. Sosinsky (2011, p. 63)  Elasticidade e Escalabilidade: a elasticidade e a escalabilidade estão vinculadas diretamente com o pool de recursos e os serviços sob demanda. Estes conceitos garantem a possibilidade de crescer gradativamente o ambiente tecnológico para cada tipo de necessidade de forma automática ou manual. Em uma demanda inicial, pode-se utilizar X ciclos de processamento, memória e armazenamento, e estes ciclos podem aumentar dinamicamente conforme a necessidade. Do ponto de vista do cliente, os recursos podem ser adquiridos em qualquer quantidade e em qualquer momento. Sosinsky (2011, p. 63)  Serviço Medido: os recursos utilizados pelo usuário em determinado período são mensurados, de forma que seja possível a identificação da quantidade memória, CPU, I/O (Input/Output) de disco, ou utilização da rede que foram de fato consumidos. A partir deste relatório, o usuário é tarifado, baseado nas métricas de utilização. Sosinsky (2011, p. 64)  Acesso Amplo à Rede: capacidade da rede possuir arquiteturas heterogêneas, de modo que diversos dispositivos como celulares, tablets, laptops e desktops possam acessar o ambiente em qualquer local e a qualquer momento. Sosinsky (2011, p. 63)
    • 35 2.1.5 Arquiteturas Podemos classificar os modelos de arquitetura da nuvem em quatro principais tipos. Não há um modelo que tenha vantagem sobre outro, a utilização destes modelos vai depender da necessidade de cada corporação, questões de custo, necessidades regulatórias, ou questões de segurança da informação. 2.1.5.1 Público O modelo público é aquele em que a nuvem tem os seus recursos compartilhados entre o público geral. Apesar de existir uma divisão lógica que garanta a separação entre todos os usuários, sua infraestrutura física é a mesma para todos (Sosinsky, 2011, p. 48). De pontos positivos, é possível citar o baixo custo e a grande quantidade de oferta no mercado. Como aspecto negativo, é possível relatar problemas de desempenho e segurança das informações quanto a sua confidencialidade e disponibilidade, afinal, todos os dados estão alocados em meios de armazenamento compartilhados. 2.1.5.2 Privado O modelo privado, diferentemente do modelo público, é exclusivo de um usuário ou um grupo. Ele pode estar situado dentro de uma corporação ou pode estar alocado em um terceiro que garanta a sua utilização exclusiva. Este modelo assegura que a infraestrutura será de uso dedicado, sem que haja o compartilhamento de recursos. Sosinsky (2011, p. 48). Dentre os pontos positivos, está a garantia de segurança dos dados, e o desempenho que este modelo pode garantir. Os pontos negativos assinalam para o alto custo que um modelo como este pode representar, por necessitar de uma infraestrutura dedicada, em que não exista a concorrência por recursos computacionais.
    • 36 2.1.5.3 Comunitário Também é possível trabalhar de forma mais segura do que o ambiente público, sem ter que realizar o investimento total de um modelo privado. Neste caso, há caracterizado o modelo chamado comunitário, em que duas ou mais organizações realizam investimentos em comum acordo, para viabilizar a utilização de um modelo privado, compartilhando os recursos entre ambas. Ainda se pode destacar neste modelo, os mesmos problemas com segurança e desempenho que existem no modelo público, mas minimizados com a redução do número de participantes de uma infraestrutura. Sosinsky (2011, p. 48). 2.1.5.4 Híbrido Quando existe a união de dois ou mais modelos destacados anteriormente, consideramos um modelo do tipo híbrido. Este é um dos modelos mais promissores da Cloud Computing, pelo fato de utilizar as vantagens dos demais modelos, e ser uma alternativa inicial para as corporações que desejam começar a utilizar serviços da nuvem. Por exemplo, um cliente que esteja preocupado com a segurança e disponibilidade de seus dados, poderia utilizar um modelo privado, mas quando utilizar a nuvem para alocação de dados não críticos, poderia utilizar o modelo público que lhe atenderia da mesma forma que o modelo privado, mas sem o seu alto custo. Sosinsky (2011, p. 48). 2.1.6 Tipos de Serviço Além dos modelos de arquitetura existentes da nuvem, ela também é classificada quanto ao tipo de serviço que é prestado com a nomenclatura “como um serviço”, ou na língua inglesa, “as a service”. Ofertar tudo como serviço faz parte da estratégia de ascender a computação nas nuvens ao modelo de utilidade. A lista de tipos de serviços oferecidos é extensa, mas serão citados aqui os principais tipos, conforme se observa a seguir. Velte Ant; Velte Tob et al., (2011, p. 11)  IaaS (Infrastructure as a Service)  PaaS (Platform as a Service)
    • 37  SaaS (Software as a Service) Figura 4 - Limites entre IaaS, PaaS, SaaS Fonte: CSA (2011b). A figura anterior explana as delimitações entre IaaS, Paas e Saas. Com base nisso, se pode classificar o modelo IaaS como responsável por manter uma infraestrutura física; o modelo PaaS em entregar uma solução para o desenvolvimento e execução de aplicações; e o modelo SaaS por entregar uma aplicação final e pronta para uso.
    • 38 Naturalmente, já existem outras definições para diferentes tipos de serviços, conforme ocorre o crescimento da evolução dos serviços na nuvem. Sosinsky (2011, p. 53, tradução nossa), reforça que: os três tipos de modelos de serviços em conjunto, têm vindo a ser conhecido como o modelo SPI (SaaS, PaaS, IaaS) da computação em nuvem. Muitos outros modelos de serviço também já foram mencionados: StaaS, armazenamento como um serviço; IdaaS, Identidade como um serviço; CmaaS, compliance como um serviço, e assim por diante. No entanto, os tipos de serviço SPI abrangem todas as outras possibilidades. 2.1.6.1 Infraestrutura como um Serviço Conforme ilustrado pela figura 5, o modelo IaaS é a base de apoio de todos os demais modelos. Nele são fornecidos serviços ligados ao hardware e equipamentos de infraestrutura. De acordo com Sosinsky (2011, p. 52), a grande vantagem deste tipo de utilidade é que um usuário não precisa se preocupar com quais equipamentos serão adquiridos para sua utilização, já que seu prestador de serviço irá garantir todos os recursos necessários. Sua preocupação é focada em dimensionar a quantidade de recursos tecnológicos que irá precisar para executar determinada tarefa, e seu custo ficará definido pela quantidade cumulativa dos recursos que utilizar. Um usuário, por exemplo, poderia adquirir os tipos de serviços IaaS conforme citados abaixo:  ciclos de CPU;  quantidade de memória;  espaço de armazenamento;  velocidade de link de dados;  firewalls e roteadores. Para o prestador de serviços, a grande vantagem é que ele poderá compartilhar sua infraestrutura física, e comercializar os serviços para diversos locatários ao mesmo tempo. Outra característica do IaaS é que os recursos podem ser dinamicamente ajustados, conforme a demanda dos serviços. Um usuário, por exemplo, poderia utilizar X ciclos de CPU e memória em uma situação normal de
    • 39 utilização de seus serviços e aumentaria dinamicamente para Y ciclos de CPU e memória em momentos de grande demanda por parte das atividades que executa, sem que precise, para isso, realizar mudanças físicas em seu ambiente. Velte Ant; Velte Tob et al.(2011, p. 15) 2.1.6.2 Plataforma como um Serviço O PaaS é um modelo executado acima do modelo IaaS (vide figura 5), e tem como objetivo fornecer um meio compartilhado para que se possa criar e executar aplicativos e serviços na nuvem. Velte Ant; Velte Tob et al., (2011, pag. 14) cita alguns exemplos de utilização do PaaS que incluem principalmente:  ambientes de desenvolvimento com bancos de dados;  desenvolvimento de sistemas;  integração de serviços web;  hospedagem de serviços;  utilização de sistemas operacionais. O modelo PaaS, assim como os demais tipos de serviços, podem atribuir vantagens ao usuário final e ao fornecedor do tipo de serviço. Um usuário de um ambiente PaaS não tem controle sobre a infraestrutura, como CPU, quantidade de memória alocada e espaço de armazenamento, porém tem o controle sobre o ambiente operacional de determinada aplicação. Para o fornecedor, o modelo PaaS é muito interessante, já que pode atender a múltiplos usuários simultaneamente em uma mesma estrutura. Um dos pontos contrários aos PaaS é que a interoperabilidade e a portabilidade entre fornecedores é prejudicada pelo fato de utilizarem soluções de padrões diferentes e incompatíveis, dificultando a migração entre fornecedores. Velte Ant; Velte Tob et al., (2011, pag. 14) 2.1.6.3 Software como um Serviço Conforme ilustrado na figura 5, o SaaS está acima da camada do PaaS, referenciado como uma aplicação final. De acordo com Miller (2008, p. 40), o
    • 40 modelo SaaS é, provavelmente, o mais conhecido e difundido da Computação nas Nuvens. Segundo Velte Ant; Velte Tob et al., (2011, pag. 12), este modelo proporciona aplicativos para serem utilizados por meio da Internet, sem que o cliente precise se preocupar com a infraestrutura necessária para utilizá-lo. O propósito central é que o usuário possa acessar aplicativos utilizando um navegador de páginas em qualquer lugar e a qualquer momento. Será de responsabilidade do provedor do serviço manter toda a infraestrutura necessária para que o software seja executado adequadamente. Miller (2008, p. 40, tradução nossa) também descreve que, cada organização servida pelo fornecedor é chamada de um inquilino, e esse tipo de arranjo é chamado de arquitetura multi-inquilino. Os servidores do fornecedor são virtualmente particionados para que cada organização trabalhe com uma instância de aplicativo virtual personalizado. Também é reforçado por Velte Ant; Velte Tob et al., (2011, pag. 14) que, o SaaS difere das antigas distribuições de soluções de computação, uma vez o SaaS foi desenvolvido especificamente para uso de ferramentas web, como o navegador. Isto torna-os web-nativos. Foi construído também com um múltiplo back-end, que permite a múltiplos clientes usarem o mesmo aplicativo. Como o ambiente é compartilhado entre diferentes usuários, o fornecedor que disponibiliza serviços de SaaS terá o seu trabalho reduzido para efetuar atualizações e manutenções, na medida em o fará em apenas poucos locais, diferentemente do modelo existente, onde cada usuário precisa executar sua própria atualização, ou mesmo manutenção. 2.2 A SEGURANÇA E OS LIMITES DA COMPUTAÇÃO NAS NUVENS Um dos grandes percalços na caminhada em direção à utilização da nuvem é a preocupação quanto à segurança da informação. Além disso, a nuvem também tem suas limitações e pode não se adequar a realidade de todos os ambientes. As corporações se preocupam muito quanto à confidencialidade, à disponibilidade e à integridade dos dados. Quando dados sensíveis são enviados para a nuvem, espera-se que eles sejam mantidos seguros, livres de acessos não autorizados e
    • 41 que se mantenham íntegros. Também é indispensável que estes dados estejam sempre disponíveis, a qualquer hora e em qualquer lugar. 2.2.1 Principais Preocupações Uma pesquisa foi realizada pelo IDC e apresentada por Velte Ant; Velte Tob et al., (2011, pag. 35), conforme ilustrada na figura 6, esta investigação apresenta a opinião de 244 executivos de TI sobre a utilização de serviços na nuvem. Do total de entrevistados, um grupo de 74,5% mostrou preocupação com a segurança de suas informações. Outros dois grupos com 58%, mostraram preocupação com a disponibilidade das informações e com o desempenho de soluções migradas para a nuvem. Figura 5 - Pesquisa sobre Computação nas Nuvens Fonte: Velte Ant; Velte Tob et al., (2011, pag. 35) Assim como ocorrem nas estruturas locais de TI, também podem ocorrer na nuvem diversos tipos de ataques que buscam acessar informações privilegiadas, ou mesmo interromper serviços ativos. De acordo com Velte Ant; Velte Tob et al., (2011, pag. 31), de fato existem muitos riscos na utilização da nuvem, porém muitas empresas provedoras de serviço estão se esforçando ao máximo em manter todo o ambiente da cloud computing seguro. Muitas vezes o ambiente mantido na nuvem pelo provedor é inclusive mais seguro do que nas próprias corporações que utilizam o serviço. Os provedores de serviços utilizam normas e recomendações que visam a
    • 42 garantir um melhor nível de serviço prestado. Sosinsky (2011, p. 426, tradução nossa) reforça que: A computação em nuvem tem muitas propriedades únicas que a tornam muito valiosa. Infelizmente, muitas dessas propriedades tornaram a segurança uma preocupação singular. Muitas das ferramentas e técnicas que poderiam ser utilizadas para proteger seus dados, cumprir com os regulamentos, e manter a integridade de seus sistemas são complicados pelo fato de que você compartilha seus sistemas com os outros e, muitas vezes, terceirizam suas operações. Prestadores de serviços de computação em nuvem estão bem cientes destas preocupações e estão desenvolvendo novas tecnologias para lidar com elas. Também é importante ressaltar que é possível ter diferentes níveis de segurança em diferentes tipos de modelos de utilização da nuvem. Por exemplo, seria possível a utilização de um serviço em IaaS com um nível mínimo de segurança, e um nível maior com a utilização de serviço do modelo SaaS. A utilização dos serviços na cloud necessitará que cada corporação elabore um mapeamento dos controles já existentes na sua infraestrutura local, que verifique quais os mecanismos de segurança necessários, e que estabeleça uma relação com os controles e mecanismos que os provedores de nuvem podem fornecer. Sosinsky (2011, p. 426) Com base nas pesquisas citadas, manter de forma segura as informações armazenadas, é o principal desafio que as organizações precisam se concentrar. Ainda de acordo com Sosinsky (2011, p. 437), mecanismos de controle de acesso podem ser utilizados para mitigar os riscos da nuvem, como a autenticação, garantindo as credenciais de determinado usuário; a autorização, atribuindo aos usuários direitos e permissões de acesso e a auditoria, buscando contabilizar e registrar as ações realizadas na nuvem. 2.2.2 Limites da nuvem Como qualquer outra tecnologia, a nuvem também possui suas deficiências e que precisam ser levadas em conta antes da tomada de qualquer decisão em utilizar serviços fora dos limites das corporações.
    • 43 2.2.2.1 Confidencialidade das informações Segundo a norma NBR ISO/IEC 27001 (2006, pag. 2), a definição para confidencialidade é a “propriedade de que a informação não esteja disponível ou revelada a indivíduos, entidades ou processos não autorizados”. Quando os dados são enviados para um centro de dados terceirizado, esta propriedade pode ser quebrada, já que a garantia pela confidencialidade das informações passa a ser também de responsabilidade do fornecedor. As informações percorrem por diferentes tipos de sistemas, arquiteturas, redes de informações e estão sujeitas a serem abertas de forma silenciosa, sem que seus proprietários tenham conhecimento do vazamento de suas informações. Segundo Velte Ant; Velte Tob et al., (2011, pag. 31), quando os dados são enviadas para nuvem, perde-se uma camada de controle das informações que foram alocadas em um ambiente externo. Reese (2009, p. 100), destaca algumas situações em que a confidencialidade dos dados poderia estar comprometida; como a falência declarada de um fornecedor; um processo judicial que obrigaria o fornecedor a conceder acesso às informações; ou ainda uma falha eventual de algum processo que venha a comprometer as informações alocadas. Com base nestes relatos, percebe-se que a criptografia tem papel vital para mitigar incidentes quanto à confidencialidade dos dados. Antes das informações serem enviadas para ambientes na nuvem, os dados devem ser criptografados, garantindo consequentemente uma maior segurança. É importante ressaltar que, apesar dos benefícios resultantes da criptografia dos dados, perde-se também desempenho no acesso das informações, em razão dos cálculos matemáticos necessários para criptografar e descriptografar constantemente as informações. Além disso, mecanismos de criptografia podem não serem aplicáveis em todos os tipos de sistema, inviabilizando a utilização dos serviços na nuvem quando se é necessário o total controle das informações. 2.2.2.2 Disponibilidade de serviços A norma NBR ISO/IEC 27001 (2006, pag. 2), descreve disponibilidade como “propriedade de estar acessível e utilizável sob demanda por uma entidade autorizada”. É necessário que quando serviços são utilizados na nuvem, eles
    • 44 estejam disponíveis a qualquer momento e que tenham desempenho suficiente para atender as demandas das aplicações. O fornecedor de serviços precisa garantir a disponibilidade das aplicações, como também é necessário que ele tenha uma grande capacidade de comunicação com a Internet, visando atender todos os seus clientes de forma satisfatória com os serviços que está prestando. Do lado do cliente, também é necessário que ele também mantenha uma infraestrutura de comunicação com a Internet adequada para os tipos de serviços que irá utilizar. Ainda assim, manter uma estrutura de backup local ou mesmo em outro fornecedor de nuvem, pode ser uma boa alternativa para garantir uma maior disponibilidade dos serviços. 2.2.2.3 Tipos de aplicações Há alguns tipos de aplicações que não justificam sua movimentação para uma plataforma na nuvem, em função de suas próprias características. Por exemplo, uma aplicação que demanda uma quantidade significativa de troca de tráfego, poderia ser inviabilizada em uma estrutura na nuvem pelo seu alto custo relacionado. Além disso, aplicações legadas que não tenham condições de serem migradas, podem não serem portadas para o ambiente externo por questões de compatibilidade. É necessário que entenda-se a necessidade do negócio e das aplicações, para que seja possível uma análise prévia dos tipos de aplicações e serviços que teriam vantagens se utilizados em ambientes da cloud. 2.2.2.4 Conformidade com a legislação vigente A conformidade com a legislação vigente é outro fator que precisa ser observado. Os países possuem legislações diferentes e que podem influenciar na segurança dos dados. Países como o EUA (Estados Unidos da América) permitem ao governo o acesso às informações armazenadas na nuvem em casos de necessidades de investigações Velte Ant; Velte Tob et al (2011,p.32). Uma citação do código de prática da NBR ISO/IEC 27005 (2005, pag. xi), descreve que,
    • 45 uma outra fonte é a legislação vigente, os estatutos, a regulamentação e as cláusulas contratuais que a organização, seus parceiros comerciais, contratados, e provedores de serviço tem que atender, além do seu ambiente sociocultural. Conforme observou-se, esta definição que visa descrever as fontes para estabelecer os requisitos de segurança da informação, também trás a preocupação com a legislação vigente. Como as informações armazenadas podem estar alocadas em diversos países, é importante observar qual a legislação vigente nestes locais. Em eventuais intimações com o provedor do serviço na nuvem, os dados de todos os clientes lá alocados podem ser abertos durante uma investigação. 2.2.2.5 Multi-Inquilino De acordo com Reese (2009, p. 3), o conceito de multi-inquilino ou como definido na língua inglesa, multi-tenant é a capacidade de um sistema oferecer múltiplas instâncias de serviços compartilhando os mesmos recursos com vários usuários ao mesmo tempo. Este tipo de conceito permite que a infraestrutura seja compartilhada, reduzindo investimentos e o custo atribuído com desenvolvimento e suporte necessário para manter as aplicações. Conforme Sosinsky (2011, p. 202, tradução nossa), multi-locação também tende para a média da variabilidade intrínseca da procura individual, porque o "coeficiente de variáveis aleatórias" é sempre menor do que ou igual a qualquer uma das variáveis individuais. Com uma demanda mais previsível e menos variação, serviços na nuvem podem ser executados em maiores taxas de utilização do que os sistemas individuais. Isso permite que sistemas de nuvem operem com maior eficiência e menores custos. Entretanto, o conceito de multi-inquilino pode resultar em alguns problemas para usuários que utilizam serviços compartilhados. Quando um fornecedor determina a quantidade de recursos destinada para uma determinada infraestrutura, ele poderá realizar uma análise pela média de utilização estimada para um serviço que irá fornecer. Ocorre que se este nível médio de utilização exceder o nível previsto poderá resultar em impactos para seus clientes. Por exemplo, um determinado usuário que utiliza massivamente o acesso ao sistema de armazenamento, através de operações de leitura e gravação randômicas, afetaria provavelmente os demais usuários que estão utilizando o mesmo serviço.
    • 46 2.2.2.6 Dependência do fornecedor Certas aplicações são desenvolvidas na nuvem atendendo os requisitos de determinado fornecedor. O problema é que o usuário pode ficar sem alternativas quando necessitar da portabilidade para sistemas de outros prestadores de serviços. Como a aplicação foi desenvolvida utilizando métodos disponibilizados pelo terceiro, ela pode ficar totalmente dependente do ambiente utilizado, causando o que é chamado de “vendor lock-in”. É indispensável que os fornecedores sejam analisados, buscando entender as padronizações utilizadas, e se elas poderão ser portadas para outros sistemas sem a necessidade de adaptações. 2.2.3 Cloud Security Alliance Os problemas relacionados com segurança na nuvem evidenciaram a necessidade de existir um estudo que apontasse os principais riscos da utilização de um ambiente em cloud e como estes riscos poderiam ser mitigados. Com base nesta necessidade, uma associação sem fins lucrativos chamada CSA (Cloud Security Alliance)14 foi criada, buscando a realização de pesquisas e a identificação dos principais problemas com segurança na nuvem, sugerindo as melhores práticas de segurança no contexto da computação nas nuvens. Este grupo de estudo é apoiado por profissionais da indústria, empresas, associações e demais partes interessadas. O documento divulgado como “CSA Guidance” fruto do estudo do grupo, está atualmente na versão 3.0, e traz as definições sobre cloud computing, métodos de governança e operação da nuvem. Ele está dividido em três grandes sessões:  arquitetura da Nuvem;  governança na Nuvem;  operação na Nuvem. Além das sessões principais, o guia traz consigo quatorze domínios que tratam assuntos relacionados à segurança e arquitetura de rede da nuvem. O estudo sugere que as organizações adotem abordagens baseadas em riscos durante a 14 CSA – http://www.cloudsecurityalliance.org
    • 47 migração dos serviços para a nuvem. De acordo com o guia, uma empresa que for realizar a migração de um ativo para a nuvem, deverá classificá-lo em dados ou aplicações. A partir desta classificação, deverá avaliar os potenciais riscos quando estiverem em um ambiente da nuvem e qual a importância deles para a corporação. Com a definição de risco do ativo definida, pode-se determinar qual tipo de arquitetura utilizar: CSA (2011a).  público;  privado – interno (dentro da corporação);  privado – externo (provedor terceiro);  comunitário;  híbrido. Segundo o CSA (2011a) também é importante, nesta etapa, possuir um mapeamento de processos das aplicações e dados, buscando encontrar a arquitetura ideal e o tipo de serviço que será utilizado, seja IaaS, PaaS ou SaaS. No ambiente da nuvem, dependendo da arquitetura escolhida e do tipo de serviço para determinada aplicação, podem existir diferentes responsabilidades entre a organização que está utilizando a nuvem e o provedor do serviço. A ilustração a seguir apresenta as responsabilidades entre os tipos de modelos computacionais da nuvem, visando o entendimento das responsabilidades entre a organização e o provedor de serviço da nuvem.
    • 48 Figura 6 - Responsabilidades entre modelos computacionais da nuvem Fonte: CSA GUIA PT-BR (2011b).
    • 49 2.3 VIRTUALIZAÇÃO Apesar de não ser um requisito obrigatório, a virtualização é um dos motores que impulsionaram a computação nas nuvens. Esta tecnologia busca aproveitar melhor os recursos computacionais, evitando desperdícios e garantindo, principalmente, flexibilidade na criação e movimentação de máquinas virtuais. O conceito de virtualização iniciou a partir de ano de 1960, quando a IBM15 utilizou seus grandes mainframes16 para dividi-los em diversas máquinas virtuais, buscando maximizar a eficiência da utilização dos grandes computadores. Dessa forma, era possível que diversas máquinas virtuais trabalhassem ao mesmo tempo, compartilhando recursos. Com o passar dos anos, por volta de 1980, o modelo cliente-servidor dos processadores x8617 acabou dominando o mercado da tecnologia de computadores, deixando a virtualização em desuso. A tecnologia x86 tinha um baixo custo e permitia um modelo de computação distribuído. Neste modelo era possível que servidores com processadores x86 de alto poder de processamento executassem aplicações para diversas máquinas clientes ao mesmo tempo. Blokdijk; Menken (2009, p. 11) Os processadores foram evoluindo ao longo dos anos, crescendo verticalmente em capacidade de processamento e horizontalmente em número de núcleos. Apesar da grande evolução dos processadores, eles não eram utilizados em sua totalidade, passando a ficar ociosos durante sua maior parte da carga de trabalho. Somado a isto, novas necessidades surgiam, buscando reduzir custos com TI, e aumentando a disponibilidade de sistemas computacionais. A solução para isso seria a volta da tecnologia de virtualização iniciada na década de 1960. A VMware18 introduziu em 1999 a primeira solução para virtualização em processadores x86, resgatando a tecnologia que havia sido deixada para trás. Blokdijk; Menken (2009, p. 12) 15 IBM – International Business Machines – Empresa situada nos EUA, voltada para a área de informática. 16 Mainframe – Computador de grande porte, com alto poder de processamento. 17 Tipo de arquitetura de processadores 18 VMware – Empresa situada nos EUA, desenvolvedora de software para virtualização.
    • 50 A tecnologia de virtualização evoluiu muito a partir do ano de 1999. Nos dias atuais é possível encontrar soluções de diferentes fabricantes que possuem soluções para virtualização, para diferentes plataformas e tipos de serviços. 2.3.1 Vantagens A virtualização oferece uma série de vantagens, buscando maximizar a utilização dos recursos de TI e reduzindo consequentemente seu custo. Dentre as vantagens, é possível citar:  redução no custo de infraestrutura;  aumento de disponibilidade de sistemas;  melhor aproveitamento de recursos ociosos;  maior taxa de consolidação;  menor tempo para entrega de serviços computacionais;  facilidades na recuperação de desastres;  gerenciamento centralizado;  economia de espaço físico. 2.3.2 Desvantagens A utilização da virtualização possui uma série de benefícios, entretanto também traz algumas desvantagens em sua adoção como:  alto consumo de memória física, podendo ser um gargalo na infraestrutura física;  concentrador de risco, quando há mais de uma máquina virtual em um mesmo hardware;  perda de desempenho quando comparado ao hardware físico;  segurança na camada de virtualização.
    • 51 É evidente que as desvantagens citadas são pequenas, se comparadas com as vantagens da tecnologia. Estas desvantagens podem ser facilmente analisadas e mitigadas através de análises pontuais dos riscos. 2.3.3 Virtual Machine Monitor Segundo Sosinsky (2011, p. 202), uma VMM (Virtual Machine Monitor) ou hypervisor como também é referenciado, é um programa de baixo nível para fornecer ao sistema operacional acesso a recursos da máquina física. A virtualização pode ser classificada em dois tipos de arquitetura, o “tipo I” e o “tipo II”. O “tipo I” adiciona uma camada de virtualização entre o hardware e o sistema operacional convidado, garantindo um melhor desempenho, evitando a competição de processos entre o sistema operacional convidado e a camada de virtualização. Um hypervisor que executa um sistema operacional convidado no “tipo I” pode trabalhar como uma virtualização completa de processador (Full Virtualization) ou como uma para-virtualização (paravirtualization). Na virtualização completa, a máquina virtual tem acesso direto às instruções do processador, garantindo em algumas ocasiões um melhor desempenho. Na para-virtualização, é necessário uma interface entre o hypervisor e a máquina virtual que está sendo executada, geralmente modificando o sistema operacional convidado e garantindo, assim, um melhor desempenho. Sem a interface, ocorre uma emulação completa do hardware, reduzindo o desempenho da máquina virtual. Sosinsky (2011, p. 202) Já a virtualização de “tipo II”, tem instalada a camada de virtualização dentro de um sistema operacional hospedeiro subjacente. O grande problema do tipo II é que o sistema operacional hospedeiro irá concorrer na utilização de recursos com a camada de virtualização, afetando o desempenho dos sistemas operacionais convidados. Quando o “tipo II” executa uma máquina virtual, ela está virtualizada por meio da para-virtualização, da virtualização total, ou por meio de uma emulação completa de hardware. Sosinsky (2011, p. 203) É importante ressaltar que, para que a virtualização completa possa ter um desempenho maior que a para-virtualização, é necessário que o processador esteja preparado para entender as instruções corretas. Os processadores mais recentes da
    • 52 Intel19 e AMD20 possuem suporte aos recursos VT-x e AMD-V respectivamente, que garantem a possibilidade de execução da virtualização completa com o maior desempenho possível. Este tipo de virtualização com suporte nos processadores, também é conhecido como a virtualização com hardware assistido. Quando o recurso de virtualização no processador é inexistente, os hypervisors para- virtualizados costumam ter um desempenho superior que a virtualização completa, pois conseguem analisar rapidamente as requisições das máquinas virtuais por meio da modificação existente no sistema operacional convidado. Mattos (2012) Em grande parte das instalações, o “tipo I“ é utilizado para provedores de serviço ou corporações com serviços locais de TI que buscam o melhor desempenho para as máquinas virtuais. Já o “tipo II”, é comumente utilizado para desenvolvimento e homologação de aplicações, ou mesmo para utilização doméstica. A figura 8 exemplifica a arquitetura de um ambiente virtual conhecido como virtualização de “tipo I” e o “tipo II”. O modelo “tipo I” é o mais utilizado para consolidar aplicações legadas da TI local de uma corporação. 19 INTEL - Empresa multinacional de tecnologia dos Estados Unidos da América. 20 AMD - Advanced Micro Devices – Empresa multinacional dos Estados Unidos da América.
    • 53 Figura 7 - Tipos de arquitetura de virtualização. Fonte: Elaborado pelo autor. 2.3.4 Soluções de Virtualização Existem, atualmente, inúmeras soluções com o propósito de realizar a virtualização de máquinas virtuais. Algumas soluções trabalham exclusivamente com o “tipo I“, e outras com o “tipo II”. Este trabalho irá apresentar brevemente as soluções Qemu, KVM, Xen, VirtualBox e o VMware ESX. Estes hypervisors citados estão entre os mais utilizados para ambientes de produção e também para ambientes de testes e homologação.
    • 54 2.3.4.1 Kernel-based Virtual Machine O KVM (Kernel-based Virtual Machine), mantido pela RedHat21 , é uma solução de código aberto para a infraestrutura de virtualização de máquinas virtuais e utilizado concomitantemente com o emulador e virtualizador Qemu. O KVM é instalado como um módulo do kernel do Linux e foi originalmente desenvolvido para arquitetura x86 e x86_64. Para utilizar o KVM é necessário que o processador do hardware hospedeiro contenha a extensão de virtualização disponível nos processadores AMD ou INTEL. O KVM executa em modo de virtualização completa de processador, embora utilize a para-virtualização para dispositivos de entrada/saída. Kvm (2011) 2.3.4.2 Qemu O Qemu é uma aplicação de código aberto que realiza a emulação e virtualização de máquinas virtuais. O Qemu pode trabalhar em modo usuário para emulação de sistemas operacionais e para diferentes plataformas de CPU ou no modo de virtualização completa, onde consegue virtualizar completamente a arquitetura de hardware para uma máquina virtual. É importante ressaltar que o Qemu é utilizado como complemento de virtualização para diversos hypervisors. Nestes casos, o Qemu é empregado para a para-virtualização de dispositivos de entrada/saída. É possível citar entre eles o KVM, Xen e Virtualbox. Qemu (2012a) 2.3.4.3 Xen O Xen é uma plataforma de código aberto para realizar a virtualização de máquinas virtuais de diversas arquiteturas como x86 e x86_64, além de outras. O Xen possui variações da sua plataforma, que trabalham como “tipo I“ ou “tipo II”, e também da forma para-virtualizada ou virtualização completa. Assim como o KVM, o Xen necessita que o processador do hardware hospedeiro contenha a extensão de virtualização disponível nos processadores AMD ou INTEL, para que possa realizar a virtualização completa. A plataforma Xen é uma das mais utilizadas atualmente e 21 RedHat – Empresa multinacional com base nos Estados Unidos da América que produz software baseado no sistema operacional Linux.
    • 55 empregada, também, como base para soluções proprietárias de virtualização como o XenServer22 da Citrix Systems e como solução de virtualização da Oracle23 , conhecida como Oracle VM24 . Xen (2012) 2.3.4.4 Vmware ESX O VMware ESX é uma solução proprietária de virtualização pertencente a corporação VMware, Inc., subsidiária da EMC Corporation25 . O hypervisor do VMware ESX trabalha no “tipo I” e permite a virtualização de diversos sistemas operacionais no modo para-virtualizado ou virtualização completa. Vmware (2012b) 2.3.4.5 Virtualbox O Virtualbox é uma solução de virtualização pertencente a Oracle e que utiliza como modelo de trabalho o “tipo II” de virtualização. O VirtualBox é instalado em um sistema operacional hospedeiro realizando a para-virtualização ou, ainda, a virtualização completa, quando o processador possuir suporte a extensão de virtualização ativa. Por trabalhar exclusivamente com o “tipo II”, o VirtualBox tem uma maior adoção em ambientes domésticos e de homologação. Virtualbox (2012) 2.4 O ARMAZENAMENTO DE DADOS Assim como a virtualização, as tecnologias de armazenamento de dados são de suma importância para o crescimento da computação nas nuvens. Muitas tecnologias foram desenvolvidas e aprimoradas para garantir o máximo de confiança quanto se fala de armazenamento de dados. Existem diversas alternativas de arquiteturas para armazenamento de informações, sejam elas de acesso local ou acesso compartilhado em redes de dados, das quais podemos citar os tipos de storage DAS (Direct Attached Storage), NAS (Network Attached Storage) e SAN (Storage Area Network). A palavra da língua inglesa “storage”, que na tradução do 22 XenServer – Solução proprietária de virtualização - www.xensource.com. 23 Oracle – Empresa multinacional de tecnologia dos Estados Unidos da América. 24 Oracle VM - http://www.oracle.com/us/technologies/virtualization 25 EMC Corporation - Empresa multinacional fornecedora de sistemas para infraestrutura e situada nos Estados Unidos da América.
    • 56 português brasileiro significa “armazenamento”, é um termo técnico utilizado e generalizado como um dispositivo centralizado para o armazenamento de dados. 2.4.1 Direct Attached Storage O storage do tipo DAS utiliza uma conexão direta entre o storage e o host cliente. Todas as requisições de acesso ao disco são feitas diretamente para o storage, que pode ser desde um simples disco conectado, até um equipamento storage dedicado em configuração raid 26 ativa, para o armazenamento de dados. Tecnologias como PATA (Parallel Technology Attachment), SCSI (Small Computer System Interface), SATA (Serial Advanced Technology Attachment), SAS (Serial Attached SCSI) e FC (Fibre Channel) são algumas tecnologias de conexões utilizadas em modelos do tipo DAS. Sacks (2001) 2.4.2 Network Attached Storage Um equipamento de storage do tipo NAS é aquele que fornece um meio de armazenamento de dados por meio de uma rede LAN (Local Area network), utilizada concomitantemente com a estrutura existente para a comunicação de serviços de rede baseados em TCP/IP. Normalmente estes tipos de dispositivos são servidores ou equipamentos dedicados com vários discos de armazenamento de dados. Estes discos, geralmente, participam de um grupo de raid, buscando um maior desempenho de I/O (Input/Output) de dados e redundância de discos. Para a comunicação do NAS com os clientes (hosts), normalmente utilizam-se protocolos como o CIFS (Common Internet File System) e o NFS (Network File System). Sacks (2001) 2.4.3 Storage Area Network Storage Area Network é a forma de armazenamento de dados utilizando uma rede de dados dedicada, exclusivamente, para o tráfego de informações. Este tipo de storage é indicado para aplicações que necessitam de um alto desempenho para 26 Raid – Tipo de tecnologia utilizada para criar uma redundância em um conjunto de discos independentes, além de oferecer mais desempenho para o acesso e gravação de dados.
    • 57 o acesso aos dados, ao mesmo tempo em que necessitam da escalabilidade para o crescimento futuro. Em uma mesma rede SAN, podem estar disponíveis vários equipamentos de armazenamento de dados, os quais são acessados por diversos hosts simultaneamente. Usualmente, a comunicação dos dados em uma rede SAN pode ocorrer utilizando a tecnologia de transporte de dados FC, ou utilizando o protocolo de internet IP conhecido como iSCSI (Internet Small Computer System Interface), que utiliza como meio de transporte a rede do tipo ethernet. Assim como os equipamentos NAS, os discos de um equipamento do tipo SAN, geralmente participam de um grupo de raid buscando um maior desempenho de I/O (Input/Output) de dados e redundância de discos. Sacks (2001) Também é importante ressaltar, que em uma SAN os discos de armazenamento são apresentados aos seus clientes como uma LUN (Logical Unit Number). Uma LUN é uma referência utilizada para identificar uma unidade lógica em uma rede SAN. Por exemplo, um dispositivo SAN disponibiliza uma determinada LUN de nome lun0 com determinado volume e mapeia esta LUN para um host específico. Sacks (2001)
    • 58 3 SOLUÇÃO PARA GERÊNCIA DA INFRAESTRUTURA DA NUVEM Neste capítulo, serão abordadas as diversas soluções para orquestrar um ambiente de infraestrutura da nuvem. A sessão 3.1 irá definir o conceito de orquestrar a nuvem, enquanto a sessão 3.2 irá apresentar as diversas soluções existentes, bem como uma análise parcial das soluções de IaaS existentes. As sessões 3.3 e 3.4 irão apresentar em maiores detalhes, as soluções Eucalyptus e Openstack respectivamente. Por fim, a sessão 3.5 irá apresentar um estudo comparativo entre OpenStack e Eucalyptus. 3.1 ORQUESTAR O AMBIENTE DA NUVEM Segundo o dicionário MICHAELLIS (2009), a palavra orquestrar significa “Compor as diferentes partes de uma peça musical para ser executada por orquestra” ou ainda “Orquestrar os componentes de uma equipe”. Em uma orquestra sinfônica, grupos orquestrais são regidos por um maestro que tem a responsabilidade de conduzir estes grupos a um objetivo final, a apresentação ao grande público. Fazendo uma analogia com a Computação nas Nuvens, o maestro, é a aplicação que controlará os diferentes tipos de sistemas de virtualização, as diferentes plataformas de armazenamento, as atribuições e os controles de acesso, delineando, por fim, a estrutura que será disponibilizada ao usuário. Os conceitos de virtualização e armazenamento centralizado são, atualmente, bem compreendidos e utilizados por grande parte das corporações, mas a grande oferta de soluções e padrões estabelecidos evidenciou o desafio existente em orquestrar esta variedade de soluções e garantir uma organização e simplificação do ambiente na nuvem. 3.2 SOLUÇÕES DE IAAS EXISTENTES Nesta sessão serão descritas soluções de IaaS utilizadas como referência para o desenvolvimento deste trabalho. Os principais serviços da Amazon serão descritos e, conforme citado anteriormente neste trabalho, também existem diversas soluções de código aberto que foram desenvolvidas e estão disponíveis para realizar
    • 59 o gerenciamento de uma infraestrutura para a nuvem. O quadro abaixo apresenta seis principais soluções escolhidas. Quadro 2 - Soluções para gerenciamento de ambientes IaaS. Nome Tipo de Plataforma Versões código Arquitetura Amazon AWS IaaS Proprietário Público Eucalyptus IaaS Proprietário/Aberto Privado/Híbrido Nimbus IaaS Aberto Privado/Híbrido OpenNebula IaaS Aberto Privado/Híbrido OpenStack IaaS Aberto Público/Híbrido/Privado Fonte: Elaborado pelo autor. 3.2.1 Amazon Web Services A Amazon é uma grande empresa de comércio eletrônico dos EUA, que no ano de 2002 começou a oferecer serviços na internet conhecidos como AWS27 (Amazon Web Services). Estes serviços evoluíram ao longo dos anos e, de forma pioneira, a Amazon aprimorou sua estrutura de modo a oferecer serviços sob demanda. Atualmente, os serviços da AWS formam um conjunto de soluções para oferecer IaaS para empresas e usuários domésticos. A Amazon possui zonas de sua infraestrutura espalhadas em algumas localidades do mundo, incluindo o Brasil, onde está instalada na cidade de São Paulo. Amazon (2012c) Dentre os diversos serviços oferecidos, este trabalho irá destacar três principais: EC2 (Elastic Compute Cloud): Serviço que oferece capacidade de computação redimensionável na nuvem. Com o EC2 é possível gerenciar instâncias de máquinas virtuais em poucos minutos, escalonando para mais ou para menos a quantidade de recursos necessários. Além das diversas características, o EC2 fornece um conjunto de funções que podem ser executadas via API. Estas funções permitem que sistemas de gerenciamento de terceiros sejam integrados com a 27 AWS – http://aws.amazon.com
    • 60 estrutura EC2 da Amazon, possibilitando a criação de instâncias, grupos de segurança, controles de acesso, entre outros. Amazon (2012a) EBS (Elastic Block Store): O serviço EBS fornece volumes de armazenamento em bloco para a utilização com instâncias EC2. Os volumes EBS são armazenados fora da instância e garantem uma vida independente da instância. Os volumes EBS podem ser utilizados para banco de dados, sistema de arquivos ou acesso a um armazenamento bruto do bloco. Amazon (2012e) S3 (Simple Storage Service): Assim como o EBS, o S3 fornece um serviço de armazenamento de dados, porém com utilização projetada para utilização na internet via protocolo HTTP28 ou BitTorrent29 . Outra grande diferença do S3 para o EBS é que o EBS mantém os dados apenas em uma zona da Amazon, enquanto o S3 pode replicar os dados do volume ao longo das demais zonas, garantindo réplicas dos dados alocados. Em contrapartida, a velocidade de leitura e gravação de dados ao S3 pode ser menor se comparada com o EBS. Além disso, o S3 permite manter imagens de estado (snapshots) do serviço EBS, garantindo, assim, backups dos volumes EBS. Também é fornecido pelo S3 interfaces de integração (API) SOAP e REST para o gerenciamento de arquivos. Amazon (2012b) 3.2.2 Nimbus O Nimbus é uma plataforma focada na infraestrutura da computação nas nuvens. Possui integração com Xen e KVM, e é compatível como o padrão de API EC2 e S3 da Amazon. Apesar de ele poder ser utilizado tanto para provedores que desejam oferecer serviços em nuvem como para usuários finais ou desenvolvedores que precisam testar aplicações, ele tem um forte apelo acadêmico, o qual é utilizado para gerenciar alguns tipos de aplicações legadas. Nimbus (2012a) 3.2.3 OpenNebula O OpenNebula, é um projeto de código aberto que busca desenvolver uma padronização para a indústria, com o objetivo de gerenciar ambientes virtualizados e 28 HTTP - Hypertext Transfer Protocol – Protocolo utilizado para comunicação de sites web. 29 BitTorrent – Protoloco de transferências de arquivos em topologia peer-to-peer.
    • 61 infraestrutura de uma nuvem híbrida e privada, apesar de também ser suportado para o gerenciamento de uma nuvem pública. O projeto OpenNebula foi iniciado como uma pesquisa no ano de 2005, e teve sua primeira versão disponibilizada em 2008. O OpenNebula pode gerenciar os hypervisors Xen, KVM, e VMware além de suportar integração com o modelo de API EC2 da Amazon. Opennenula (2012a) 3.2.4 Eucalyptus O Eucalyptus é uma aplicação madura, open-source, que trabalha com alguns tipos de hypervisors como o Xen e KVM, e realiza a integração com o padrão de API EC2 e S3 da Amazon. Iniciado a partir de um projeto de pesquisa da Universidade da Califórnia, Santa Barbara em 2007, ele foi desenvolvido com base na infraestrutura do fornecedor de IaaS Amazon, buscando adicionar suas principais características e funcionalidades. O Eucalyptus possui duas divisões internas, uma divisão open-source baseada na licença GPL v3, e outra proprietária. A licença proprietária disponibiliza outras funcionalidades, como integração com hypervisor VMware ESX e suporte técnico, que não estão inclusas na versão open-source. Eucalyptus (2012b) 3.2.5 OpenStack O Openstack é uma solução de gerência de uma nuvem IaaS, seu código é totalmente livre e surgiu em 2010, fruto de um de projeto de pesquisa e desenvolvimento a partir da união da NASA (National Aeronautics and Space Administration) dos Estados Unidos e da empresa privada de infraestrutura, Rackpace. O conceito principal do Openstack, que está baseada na licença Apache 2.0, é fornecer uma plataforma de gerenciamento de infraestrutura neutra e compatível com o maior número possível de desenvolvedores de aplicações e infraestrutura. O OpenStack pode controlar os hypervisors Xen/XenServer, KVM, VMware/ESX, LXC (Linux Containers) UML (User Mode Linux), Hyper-V, Qemu e também realiza a integração com o padrão de API EC2 e S3 da Amazon. OpenStack (2012b)
    • 62 3.2.6 Análise Parcial das Soluções As soluções apresentadas neste trabalho têm como foco principal a implantação de um modelo de IaaS, oferecendo infraestrutura como um serviço para seus usuários. Cada solução tem suas peculiaridades e pode ser utilizada em diferentes ambientes. Os serviços AWS30 (Amazon Web Services) da Amazon, conforme citado anteriormente neste trabalho, formam um conjunto de soluções para oferecer infraestrutura como um serviço. Pelo grande sucesso obtido por meio dos serviços AWS, acabou sendo referência para outras soluções. Todas as soluções que foram citadas neste trabalho possuem suporte para a integração de API com os serviços S3 e EC2 da Amazon. De acordo com a análise realizada por Sempolinski; Thain (2010), o Nimbus é um projeto com um longo tempo de vida, integrado com o projeto de computação em grid, o Globus Project31 , e tem um foco maior voltado para pesquisas científicas. O OpenNebula pode ser considerada uma solução mais interessante, devido ao fato de integra-se com grande parte dos hypervisors existentes, e oferecer escalabilidade para crescimento futuro. O trabalho de Sempolinski; Thain (2010), também realizou a análise do OpenNebula, considerando uma solução robusta e voltada para aplicação de nuvens híbridas e privadas. De acordo com Schubert (2012) um estudo realizado pela Comissão Européia, apontou o OpenNebula como uma solução promissora e com foco para o gerenciamento de nuvens híbridas e privadas. O projeto Eucalyptus é uma solução muita madura, com um grande número de participantes e segue o padrão EC2 e S3 da Amazon. O projeto é apoiado por diversas empresas e utilizado como solução para prover principalmente nuvens híbridas e privadas, ainda que possa também ser utilizada para o perfil de clientes de nuvem pública. O fato do possuir uma divisão open-source e uma proprietária com mais recursos, pode-se considerar que o Eucalyptus não é uma solução totalmente livre. O OpenStack é uma plataforma muito nova, mas atraiu a atenção de grandes empresas mundiais pelo seu potencial futuro. A solução agrupa as melhores ideias dos demais projetos de computação nas nuvens, buscando entregar uma solução 30 AWS – http://aws.amazon.com
    • 63 totalmente livre, que possa ser utilizada por grandes fabricantes e provedores de serviço de nuvem pública. Tem a participação de grandes empresas públicas e privadas, das quais se pode citar a Dell, RedHat, Microsoft, Citrix, Intel, Canonical, Cisco, HP, F5, Nasa, Rackspace, entre outras. Assim como o Eucalyptus, também é totalmente compatível com as interfaces de integração EC2 e S3. A escolha deste trabalho em utilizar o OpenStack como solução para implantação de um ambiente de gerência na nuvem, dá-se pelo fato de ser uma aplicação promissora e robusta para empresas públicas e privadas que desejam oferecer infraestrutura como serviço. Também é importante ressaltar que o Eucalyptus será utilizado como base comparativa, buscando apontar as principais diferenças entre as duas soluções. Ele foi escolhido como base comparativa, por ser a plataforma que mais se assemelha com o modelo proposto do OpenStack. 3.3 EUCALYPTUS O Eucalyptus é uma solução que gerencia um conjunto de equipamentos e sistemas, possibilitando a entrega de serviços de IaaS na nuvem. Ele permite que sejam utilizados equipamentos legados como servidores, switchs e storages, para a criação de uma nuvem privada para corporações e, híbrida, através da integração com os padrões da Amazon EC2, S3. Ele foi desenhado para ser uma aplicação modular e de fácil instalação, com suporte a recursos de alta disponibilidade. Eucalyptus Systems (2012b). 3.3.1 Principais Componentes Eucalyptus é formado por seis componentes principais, o Cloud Controller (CLC), o Walrus, o Cluster Controller (CC), o Storage Controller (SC), o Node Controller (NC) e um opcional componente para integração com o VMWare, o VMware Broker. Ele também desenvolveu um pacote de comandos para a administração do ambiente Eucalyptus, baseado e compatível com o Amazon AWS chamado euca2ools. A imagem a seguir, demonstra a arquitetura principal do Eucalyptus. Eucalyptus Systems (2012c). 31 http://www.globus.org/toolkit/
    • 64 Figura 8 - Arquitetura principal do Eucalyptus. Fonte: Eucalyptus Systems (2012c). 3.3.1.1 Cloud Controller (CLC) Utilizado por administradores, desenvolvedores, gerentes de projetos e usuários finais que buscam executar ações na nuvem, o CLC (Cloud Controller) é a porta de entrada para efetuar o gerenciamento do Eucalyptus. Ele também interage diretamente com os CCs (Cluster Controllers), gerenciando recursos como servidores, redes e armazenamento. O acesso a ele é realizado através de uma interface web administrativa, ou através de ferramentas de linha de comandos com o euca2ools. Eucalyptus Systems (2012c). 3.3.1.2 Walrus O Walrus permite aos usuários armazenar dados persistentes, organizados em containers e objetos. Ele é análogo ao serviço S3 da Amazon, e provê operações para criar, apagar, listar containers, ou enviar, obter e apagar objetos. Também é possível utilizar o Walrus para armazenar e acessar imagens de máquinas virtuais. Eucalyptus Systems (2012c). 3.3.1.3 Cluster Controller (CC) O CC (Cluster Controller) efetua o gerenciamento da localização de máquinas virtuais e também realiza o agendamento para a execução de instâncias. Através de solicitações recebidas do controlador da nuvem (CLC), o CC agenda a execução de instâncias nos controladores de nós (NCs). O CC também pode atuar como um
    • 65 roteador das máquinas virtuais, roteando entre a rede pública e a rede privada das instâncias. Eucalyptus Systems (2012c). 3.3.1.4 Storage Controller (SC) O SC (Storage Controller) provê serviços similares ao EBS da Amazon, possibilitando anexar volumes a instâncias de máquinas virtuais. Ele permite realizar a interface entre diferentes tipos de sistemas de storage (NFS, iSCSI, SAN, discos locais, entre outros). Os volumes de dados do SC são persistentes, e também é possível realizar fotos de estado (snapshots) destes volumes para serem armazenados no sistema de armazenamento de objetos Warus. Eucalyptus Systems (2012c). 3.3.1.5 Node Controller (NC) O NC (Node Controller) está localizado em máquinas físicas que executam instâncias de máquinas virtuais e é responsável por iniciar, terminar e inspecionar as máquinas virtuais. Atualmente, ele suporta os hypervisors Xen, KVM e VMWare (através do VMware Broker). Eucalyptus Systems (2012c). 3.3.1.6 VMware Broker VMware Broker é componente opcional do Eucalyptus que possibilita a integração com a plataforma VMware ESX/ESXi. Ele está disponível apenas na verão enterprise do Eucalyptus. Eucalyptus Systems (2012c). 3.3.1.7 Euca2ools O Eucalyptus também foi pioneiro e iniciou um projeto de código aberto, chamado euca2ools. Por meio de uma engenharia reversa, analisou os métodos da API dos serviços AWS da Amazon, e criou métodos semelhantes para gerenciar o ambiente IaaS do Eucalyptus e da própria Amazon. Eucalyptus Systems (2012g).
    • 66 3.4 OPENSTACK Esta sessão irá apresentar os componentes que formam o projeto Openstack, buscando descrever seus componentes, os principais conceitos e a sua arquitetura. Conforme mencionado no item 3.2.5, a concepção principal do Openstack é fornecer um software de código aberto projetado para provisionar grandes redes de máquinas virtuais criando uma estrutura redundante e escalável. Atualmente, na versão “ESSEX”, a solução é dividida em cinco principais componentes, o Openstack Compute (codinome Nova), Openstack Object Store (codinome Swift) e Openstack Image Service (codinome Glance), o Openstack Dashboard (codinome Horizon) e o Openstack identity (codinome Keystone). É importante ressaltar que, originalmente, o Openstack foi desenvolvido com três componentes principais, o Swift, Glance e o Nova. No seu último lançamento, na versão “ESSEX”, foram incorporados os componentes Horizon e Keystone. Openstack, (2012c) Escrito basicamente na linguagem Python32 , cinco versões do Openstack foram liberadas e apesar de recentes, podem ser utilizadas para ambientes de produção. Alguns exemplos são as soluções comerciais oferecidas pela Rackspace33 e a HP34 . As versões do Openstack são liberadas a cada seis meses, conforme é possível observar na tabela a seguir: Tabela 1 - Versões de lançamento do Openstack Nome Lançamento Data Lançamento OpenStack Compute versão OpenStack Object Storage versão Essex April 2012 2012.1 1.4.8 Diablo October 2011 2011.3 1.4.3 Cactus April 2011 2011.2 1.3.0 Bexar March 2011 2011.1 1.2.0 Austin October 2010 0.9.0 1.0.0 Fonte: Editado pelo autor com base em Openstack (2012f). 32 Linguagem de programação de alto nível. http://www.python.org/ 33 http://www.rackspace.com/cloud/nextgen/details/ 34 http://www.hpcloud.com
    • 67 3.4.1 Visão Global O Openstack foi projetado para entregar um sistema operacional totalmente escalável na nuvem. Desta forma, todos os serviços realizam a integração por meio de APIs, entregando serviços de infraestrutura para usuários finais, possibilitando, desta maneira, um crescimento horizontal da infraestrutura da nuvem. É possível observar, na figura a seguir, a integração entre os cinco componentes do projeto. Figura 9 - Arquitetura conceitual do Openstack. Fonte: Editado pelo autor com base em Openstack, (2012c). A seguir é descrita uma visão geral sobre cada subprojeto da família do Openstack, e também são descritos alguns outros componentes e terminologias necessários para a boa percepção do projeto OpenStack. Compute (Nova): O Nova tem a responsabilidade de prover servidores virtuais sob demanda. Ele também fornece volumes de dados para serem alocados para máquinas virtuais. O serviços providos pelo Nova são análogos ao EC2 e EBS da Amazon. Openstack, (2012c)
    • 68 Image Store (Glance): O Glance fornece um repositório e catálogo de imagens de discos virtuais. Seu uso é opcional, embora ele seja extremamente importante para o gerenciamento de imagens de grandes instalações. Openstack, (2012c) Object Store (Swift): O componente Swift fornece o armazenamento de objetos, permitindo o armazenamento e a recuperação de objetos que podem ser, por exemplo, imagens e arquivos de mídia. O Object Store do Openstack é análogo ao S3 da Amazon. Openstack, (2012c) Identity (Keystone): O Keystone é um componente para prover as funções de autenticação e autorização para todos os serviços da família do OpenStack, Openstack, (2012c) Dashboard (Horizon): O Horizon prove uma interface web modular para todos os serviços disponibilizados pelo OpenStack. Openstack, (2012c) Banco de Dados: A utilização de um banco de dados é imprescindível para a comunicação entre todos os sujeitos do projeto OpenStack. No banco de dados são armazenadas e relacionadas todas as informações do projeto de nuvem estabelecido. Evidentemente, o OpenStack não fornece um sistema de banco de dados próprio, mas possui suporte nativo para alguns tipos de bancos de dados existentes. O Keysotne, Glance e o Nova possuem conectividade com o MySQL35 , PostgreSQL36 ou SQLite37 , enquanto que o Swift, pela sua arquitetura distribuída, utiliza apenas o SQLite. Openstack, (2012c) 3.4.2 Openstack Compute (Nova) O Nova é o controlador de nuvem do OpenStack. É ele que realiza todas as ações para gerenciar o ciclo de vida das imagens (instâncias), atribuindo recursos, acesso às redes de comunicação, realizando autorizações e gerenciando toda a 35 Banco de dados de plataforma aberta. http://www.mysql.com 36 Banco de dados de plataforma aberta. http://www.postgresql.org 37 Tipo de sistema de banco de dados local - http://www.sqlite.org
    • 69 escalabilidade necessária para a nuvem do Openstack. A integração com os hypervisors pode ser realizada utilizando a libvirt API38 , ou utilizando a integração nativa do hypervisor, executada pelo próprio Nova. As atribuições a seguir, são de responsabilidade do OpenStack Nova: Openstack, (2012c)  gerenciamento do ciclo de vida de instâncias;  gerenciamento dos recursos computacionais;  rede e autorização;  API REST (Integração administrativa e pública);  comunicação assíncrona;  integração com hypervisors (Xen/XenServer, KVM, VMware/ESX, LXC (Linux Containers) UML (User Mode Linux), Hyper-V, Qemu). Conforme pode ser observado na figura a seguir, a comunicação entre os principais componentes do Nova, o nova-compute, o nova-volume, o nova-network, o nova-api, o nova-scheduler e o nova-objectstore é realizada por meio de uma fila de mensagens assíncrona, gerenciada pelo serviço RabbitMQ Server39 , que utiliza o protocolo aberto AMQP (Advanced Message Queuing Protocol). Como o Nova realiza as chamadas assíncronas para o servidor de mensagens, evita a ocorrência de bloqueios dos componentes, enquanto aguarda pela resposta de um dos outros componentes. As operações como uploads de imagens ou execução de instâncias tendem a levar algum tempo para ter o processo concluído, explicando o porquê da necessidade da troca de mensagens serem de forma assíncrona. Além disso, a comunicação entre os componentes do Nova pode ser realizada localmente ou remotamente, permitindo que eles sejam instalados em um mesmo nó ou para ambientes maiores, em diferentes nós. Por exemplo, em um ambiente com vários nós podem existir um nó com o nova-compute, um nó com o nova-network e um último nó com o nova-objecstore. Openstack (2012e). Figura 10- Arquitetura de serviços do Openstack Compute (Nova) 38 Libvirt API – http://libvirt.org - Solução de código aberto que realiza a integração com diferentes tipos de hypervisors.
    • 70 Fonte: Elaborado pelo autor com base em Openstack (2012e). 3.4.2.1 API Server (nova-api) O Nova-api é o serviço que realiza a interação com os usuários externos da nuvem. Utilizando o modelo de API EC2, ele recebe instruções externas baseado nos formatos JSON (JavaScript Object Notation) ou XML (Extensible Markup Language) e as repassa para o servidor de mensagens para efetuar a comunicação com os demais componentes. O Openstack também possui um alternativa de API, chamada de “OpenStack API”. Openstack, (2012c). 39 http://www.rabbitmq.com/
    • 71 3.4.2.2 Message Queue (Rabbit MQ Server) Conforme descrito anteriormente, o Message Queue é o servidor de mensagens que interage com os principais componentes do OpenStack, através da troca de mensagens assíncronas. O processo inicia quando um usuário envia uma solicitação via uma requisição HTTP. Antes de enviar a requisição, este usuário precisa autenticar-se e estar autorizado a enviar a requisição desejada. O serviço de mensagens verifica a disponibilidade de atender a requisição e, após a verificação de disponibilidade, coloca a requisição em uma fila para que seja atendido por um dos componentes do OpenStack. Após a conclusão da tarefa realizada pelo componente apropriado, uma resposta é enviada para a fila e remetida, finalmente, para o usuário final. Openstack (2012e). 3.4.2.3 Compute Worker (nova-compute) O nova-compute é o componente que efetua o gerenciamento do ciclo de vida de instâncias de máquinas virtuais. Ele recebe suas tarefas através de mensagens do “Message Queue” e dispara todas as solicitações necessárias (via Message Queue) para os demais componentes do Openstack, de forma que possa iniciar ou terminar o ciclo de vida de uma instância. Além do gerenciamento dos recursos como ips, espaço alocado, quota, entre outros, são responsabilidades primárias do nova-compute: Openstack (2012e).  executar instâncias (via hypervisor);  terminar instâncias (via hypervisor);  reiniciar instâncias (via hypervisor);  anexar volumes;  retirar volumes;  obter saído do console. 3.4.2.4 Network Controller (nova-network) O nova-network gerencia os recursos de rede para o ambiente das instâncias de máquinas virtuais. Ele é responsável por alocar endereços ip, configurar VLANs
    • 72 (Virtual LAN)40 para os projetos, implementar grupos de segurança e configurar as redes para nós do Openstack. O nova-network pode entregar para as instâncias dois tipos de ips, um ip privado (fixo) ou um ip público (flutuante). A configuração com o ip privado é normalmente utilizada para a comunicação interna, entre instâncias, enquanto a configuração com o ip público é utilizada para comunicação com a Internet ou como uma rede privada (não necessariamente um ip roteado para a internet). Quando uma instância é iniciada, ela recebe um ip fixo privado e permanece com a instância até ela ser encerrada. Do contrário, um ip flutuante pode ser associado e dissociado à uma instância a qualquer momento. Também é possível que endereços ips flutuantes sejam reservados por usuários para determinado projeto. Openstack (2012e). É possível configurar projetos do nova-network em três modos diferentes:  Flat Network Manager;  Flat DHCP Network Manager;  VLAN Network Manager. Para ambientes de produção, a recomendação do OpenStack é a utilização da configuração em modo “Rede VLAN”, o modo mais rico em recursos, enquanto que os outros dois modos podem ser utilizados para uma melhor familiarização do OpenStack. Openstack (2012e). No modo “Flat Network Manager”, uma configuração de sub-rede é estabelecida, e cada instância recebe um ip da sub-rede. Quando a instância é iniciada, ela obtém um ip do pool através de uma configuração baseada em um arquivo de configuração. No modo “Flat DHCP Network Manager”, um serviço de DHCP é iniciado para servir a distribuição de endereços ips. Em ambos os modos “Flat”, o nova-network será o gateway das instâncias do projeto. A figura a seguir demonstra como o nova-network realiza a tarefa de ser um gateway default das instâncias de máquinas virtuais. Openstack (2012e). 40 Isolamento virtual de redes de computadores.
    • 73 Figura 11 - Arquitetura de rede do nova-network. Fonte: Editado pelo autor com base em Openstack (2012e). Por fim, no modo “Vlan Network Manager”, uma rede virtual entre o nova- compute, o nova-network e no host onde a instância estiver sendo executada é estabelecida, de modo que seja possível realizar o isolamento lógico entre diferentes projetos do ambiente do OpenStack. Neste modo, para que seja possível a conexão externa de usuários com uma instância, é necessário que ele estabeleça uma conexão VPN (Virtual Private Network) com um endereço ip do nova-network atribuído para o projeto do usuário. 3.4.2.5 Volume Workers (nova-volume) Volume Workers são responsáveis por gerenciar volumes de dados baseados em LVM (Logical Volume Manager)41 . O armazenamento em volumes de dados é uma maneira de realizar o armazenamento persistente para instâncias, já que a partição raiz de uma instância não é persistente, levando os dados a serem perdidos quando uma instância é terminada. O nova-volume tem a responsabilidade de criar, apagar, anexar e desanexar um volume para uma instância. Como o volume de dados é persistente, é possível que este volume seja anexado para outras instâncias, mantendo a integridade dos dados. Conforme pode ser observado na imagem a seguir, o nova-volume pode conectar-se a um dispositivo de armazenamento DAS, NAS ou SAN e disponibiliza o acesso para as instâncias através do protocolo ISCSI. Para fornecer o acesso ao protoloco iscsi, ele utiliza o 41 LVM - http://tldp.org/HOWTO/LVM-HOWTO/
    • 74 serviço iscsitarget42 , que provê a capacidade de gerenciar requisições no protocolo iscsi. O nova-volume é análogo ao serviço EBS oferecido pela Amazon. Openstack (2012e). Figura 12 - Arquitetura do nova-volume.. Fonte: Elaborado pelo autor com base nas informações do Openstack (2012e). 3.4.2.6 Nova Objectstore (nova-objectstore) O nova-objectstore fornece uma interface de integração com o Swift ou com o serviço S3 da Amazon, utilizando o pacote de comandos euca2ools. 3.4.2.7 Scheduler (nova-scheduler) O nova-scheduler tem a incumbência de mapear as chamadas do nova-api, distribuindo para os componentes nova-compute e nova-volume apropriados do OpenStack. Ele tem um papel vital para o OpenStack, já que é um componente de inteligência responsável por balancear a carga de tráfego entre toda a nuvem de hosts. Por meio da utilização de um de algoritmo de escalonamento, ele utiliza um host para iniciar uma instância de um pool disponível, baseado em decisões como o fator de carga de um processador, a utilização de memória, a distância física de uma zona disponível, a arquitetura de CPU, entre outros. Os seguintes algoritmos estão disponíveis no nova-scheduler: Openstack (2012e).  Chance: neste método, um host é escolhido aleatoriamente através das zonas disponíveis. Este é o algoritmo padrão para a escolha do nova-volume. Openstack (2012e). 42 http://iscsitarget.sourceforge.net/
    • 75  Multi Scheduler: o “Multi Scheduler” mantém sub-schedulers, utilizados para diferenciar o algoritmo do nova-compute do algoritmo do nova-volume. Este é o algoritmo padrão utilizado no nova-scheduler. Openstack (2012e).  Simple: no “Simple”, os hosts que possuem a menor carga de trabalho são escolhidos. O “Simple” pode ser utilizado tanto para o nova-volume quanto para o nova-compute. Openstack (2012e).  Filter Scheduler: este algoritmo suporta filtragem e verificação de pesos para efetuar a tomada de decisão de onde uma nova instância será criada. Ele é o algoritmo padrão utilizado para o nova-compute, quando definido o “Multi Scheduler”. Este algoritmo é válido, apenas, para o nova-compute, não podendo ser utilizado para o nova-volume. Openstack (2012e). Na definição do algoritmo “Multi Scheduler”, o nova-scheduler utiliza filtros, através do algoritmo “Filter Scheduler”. Isto possibilita que um administrador determine algumas regras que serão utilizadas para determinar os hosts que receberão a execução de uma instância. O quadro abaixo apresenta os filtros disponíveis para o algoritmo “Filter Scheduler”: Openstack (2012e). Quadro 3 - Filtros para utilização no nova-scheduler. Filtro Descrição AllHostsFilter Este filtro utiliza todos os hosts disponíveis do nova-compute (host). AvailabilityZoneFilter Filtra uma zona disponível. ComputeFilter Verifica se um host tem capacidade suficiente para executar uma instância. CoreFilter Verifica se há núcleos suficientes no host para executar a instância. DifferentHostFilter Realiza uma verificação para executar uma instância apenas em um host diferente de determinadas instâncias já iniciadas. IsolatedHostsFilter Permite chavear algumas imagens para que sejam iniciadas apenas em determinados hosts e vice-versa. RamFilter Permite definir uma quantidade máxima de RAM (em percentual) que uma instância pode exceder de um host.
    • 76 SameHostFilter Ao contrário do "DifferentHostFilter", verifica quais hosts executam determinadas instâncias, para executar a próxima no mesmo host. SimpleCIDRAffinityFilter Efetua uma verificação do agendamento baseado no endereço de subnet do IP do host. nova.scheduler.least_cost.com pute_fill_first_cost_fn Não é um filtro, mas uma função para adicionar um peso na filtragem dos itens acima. Quanto menor o peso final dos hosts, maior a probabilidade de ser utilizado para iniciar uma instância. nova.scheduler.least_cost.noo p_cost_fn Função para igualar o peso de todos os hosts, não utilizado na prática. Fonte: Elaborado pelo autor com base nas informações do Openstack (2012e). Depois de efetuado o filtro dos hosts selecionáveis, um algoritmo de custo é aplicado, baseado em configurações pré-definidas, aumentando ou diminuindo a probabilidade de escolha de um host em um conjunto de hosts. A imagem a seguir apresenta o fluxo para a tomada de decisão do nova-scheduler. Openstack (2012e). Figura 13 - Fluxograma do processo de decisão do nova-scheduler. Fonte: Editado pelo autor com base em Openstack (2012e). 3.4.2.8 Tipos de Instâncias (Flavors) Tipos de instâncias ou flavors são perfis de máquinas virtuais pré-definidas em termos processamento, memória e capacidade de armazenamento. O padrão
    • 77 EC2 API define nomes dos tipos de instâncias como “m1.large” ou “m1.tiny” enquanto o Nova utiliza nomes como “512 MB Server”. A tabela a seguir, lista os principais tipos de instâncias pré-definidas pelo EC2 API e que também são utilizados pelo Nova. Tabela 2 - Tipos de instâncias pré-definidas pelo EC2. Tipo Memória VCPU Storage m1.tiny 512MB 1 0GB m1.small 2048MB 1 20GB m1.medium 4096MB 2 40GB m1.large 8192MB 4 80GB m1.xlarge 16384MB 8 160GB Fonte: Criado pelo autor com base em Openstack (2012e). 3.4.3 Openstack Storage Infrastructure (Swift) O Swift é um sistema distribuído, redundante e com alta disponibilidade para o armazenamento de objetos (eventualmente consistente). Formado pelos componentes “Proxy Server”, “Account Servers”, “Container Servers” e “Object servers”, ele é capaz de armazenar bilhões de objetos distribuídos entre os nós, provendo um meio de armazenamento global e redundante. É importante ressaltar que o Swift não disponibiliza um volume para ser montado como um sistema de arquivos, mas, sim, um sistema de armazenamento de longo prazo para tipos de dados permanentes. Semelhante ao serviço S3 da Amazon, o Swift pode ser utilizado para o armazenamento de imagens de máquinas virtuais, o armazenamento de fotos, emails, backups, entre outros. Ele também permite um crescimento horizontal, formando um cluster (através de servidores legados, ou utilizando simples servidores com discos rígidos de diferentes tamanhos) para um sistema de armazenamento com capacidade virtualmente ilimitada. A imagem abaixo demonstra uma arquitetura simples do OpenStack Swift.
    • 78 Figura 14 - Exemplo de arquitetura do OpenStack Swift. Fonte: Elaborado pelo autor com base em Openstack (2012d). 3.4.3.1 Swift Proxy Server Usuários finais que necessitam interagir com uma infraestrutura do Swift, precisam comunicar-se com um servidor “Proxy Server”, que, por sua vez, consulta os demais componentes do Swift. As requisições para o Proxy são feitas através de APIs (para criar, manipular ou remover objetos), ou utilizando o protoloco HTTP nativo (como a leitura de arquivos). Sua principal função é verificar a localização dos nós responsáveis por armazenar os “objects”, “containers” ou “accounts”, e rotear as requisições para cada respectivo nó. Além de possuir um sistema de cache através da utilização do “memcached”43 , o “Proxy Server” também efetua um tratamento de falhas das requisições efetuadas. Por exemplo, se um determinado usuário efetua a leitura de um arquivo, o Proxy irá consultar o nó que possui a cópia do arquivo e, se este estiver indisponível, tenta o próximo nó que também possui uma cópia deste arquivo. Openstack (2012d). 3.4.3.2 Swift Object Server O “Swift Object Server” é o componente que gerencia objetos (arquivos binários) nos servidores que possuem discos de armazenamento. Ele é responsável por guardar, recuperar e apagar estes objetos em seus discos locais. Estes objetos 43 http://memcached.org
    • 79 são alocados em um sistema de arquivos locais que tenham suporte para estruturação dos dados (metadata), utilizando atributos estendidos (xattrs)44 . O “Object Server” suporta diversos tipos de sistemas de arquivos que suportem atributos “xattrs”, embora recomende a utilização do sistema de arquivos XFS45 . Também é importante ressaltar que em um cluster do Swift, vários nós do “Object Server” possuem cópias de objetos de outros nós, criando, desta forma, um sistema redundante. Nativamente, o “Object Server” replica um objeto em três nós distintos. Openstack (2012d). 3.4.3.3 Swift Container Server O “Swift Container Server” mapeia os objetos em uma lista, permitindo informar os objetos de cada “Container Server”. As listas são gravadas como arquivos de banco de dados SQLite. Além disso, ele fornece estatísticas de utilização, como o número total de objetos, quantidade de utilização, armazenamento total do recipiente, entre outros. Assim como o “Object Server”, ele efetua a replicação dos mapeamentos em diferentes nós. Openstack (2012d). 3.4.3.4 Swift Account Server Similar ao “Container Server”, o “Account Server” mapeia os containers de respectivas contas de usuários. Assim como os outros componentes, também efetua a replica dos dados em diferentes nós. Openstack (2012d). 3.4.3.5 The Ring O anel (Ring) contém informações da localização física dos objetos gravados no Swift e são repassadas para o servidor Proxy. É uma representação virtual do mapeamento dos nomes das entidades para sua localização física real. Ele é análogo ao serviço de indexação de um sistema de arquivos, por exemplo. Os componentes Account, Container e Object possuem seus próprios anéis, ainda que possam estar distribuídos em um mesmo conjunto de nós. Openstack (2012d). 44 xattrs - Filesystems support extended attributes 45 http://xfs.org
    • 80 O anel mantém um mapeamento utilizando conceitos de zona, dispositivos, partições e réplicas. Na configuração nativa do Swift, cada partição do anel é replicada para mais duas partições ao longo do cluster, e o mapeamento de uma partição virtual em discos físicos é mantida também pelo anel. Os dados também podem ser isolados utilizando um conceito de zonas, possibilitando que cada réplica de uma partição esteja alocada em uma diferente zona, garantindo a disponibilidade dos dados em uma eventual pane de uma localidade. Openstack (2012d). Por exemplo, cada servidor físico possui um número de discos. Ao longo do cluster, estes discos são divididos em pequenas partições virtuais de mesmo tamanho. Estas partições virtuais, em conjunto, irão formar o anel, garantindo a indexação dos objetos e a réplica dos dados. A figura abaixo exemplifica um anel formado por partições virtuais, com réplica de três nodes. Para adicionar um novo disco, o anel movimenta algumas partições virtuais e disponibiliza novas partições para serem utilizadas. Danjou (2012). Figura 15 - Exemplo de anel utilizado no OpenStack Swift. Fonte: Editado pelo autor com base em Riak (2012) O Swift também possui alguns processos que garantem a segurança dos dados (disponibilidade, integridade e confiabilidade). O processo “replication”,
    • 81 através da aplicação rsync46 , garante a replicação íntegra dos dados entre os nós virtuais, quando erros de rede ou de disco ocorrem. O processo “updaters” garante a atualização dos “containers” ou “accounts” quando não é possível efetuar uma atualização imediata. O processo “auditors” efetua periodicamente a checagem de integridade dos “objects”, “containers” e “accounts” e replica os dados para um determinado nó virtual, se erros forem encontrados. 3.4.4 Openstack Imaging Service (Glance) O Glance provê serviços para a descoberta, registro e a recuperação de imagens de máquinas virtuais de diferentes formatos. Formado pelos componentes glance-api e glance-registry, ele mantém um catálogo e o repositório das imagens, disponibilizando para que o nova-compute inicie instâncias de máquinas virtuais. A imagem a seguir, exibe a arquitetura lógica do Glance. Figura 16 - Arquitetura lógica do OpenStack Glance. Fonte: Glance Architecture (2012) 46 - Aplicação para a replicação de dados - rsync.net
    • 82 3.4.4.1 Glance-api Assim como o nova-api, o componente glance-api é uma interface que interage com as requisições dos usuários e com os dispositivos de armazenamento, conforme é possível observar na imagem anterior. A imagem exemplifica a conexão do glance-api com clientes, com o glance-registry e com o “Store Adapter”47 . Glance (2012) O glance-api pode armazenar imagens nos seguintes dispositivos ou sistemas:  Swift (OpenStack);  Filesystem (armazenamento local);  S3 (serviço da Amazon AWS);  HTTP (apenas leitura de imagens via HTTP). Outra característica relevante do glance-api é a possibilidade de realizar o cache de imagens. Imagens utilizadas recentemente são armazenadas em um cache local do servidor glance-api, possibilitando que outros servidores de API efetuem uma rápida leitura, garantindo uma maior escalabilidade para o fornecimento das imagens. Openstack (2012j) Para que seja possível entender o processo de gerenciamento de imagens, um exemplo será citado. Um usuário deseja enviar uma imagem para o Glance, do qual utilizará posteriormente para a execução de algumas máquinas virtuais. Através de uma interface web (Horizon), ou através da execução direta de uma chamada ao glance-api, ele realiza o upload de uma imagem de um sistema operacional. Durante o processo de upload, o usuário irá aguardar até que a imagem enviada esteja no estado “active”, no qual estará pronta para ser utilizada pelo componente Nova. No quadro abaixo, são citados os possíveis estados das imagens gerenciadas pelo Glance: Quadro 4 - Estados de uma imagem no Glance. Estado Descrição 47 Classe do Python do Glance (glance.store.Backend) que realiza a comunicação com os sistemas de armazenamento.
    • 83 queued Um identificador foi criado para a imagem, mas ainda não foi iniciado o processo de upload. saving A imagem está sendo enviada para o armazenamento. Active A imagem está pronta para ser utilizada. Killed Um erro ocorreu no envio da imagem e não está disponível. deleted Os dados da imagem foram removidos, mas o Glance manteve a informação sobre a imagem. Será removida em momento oportuno. pending_delete Um processo para apagar a imagem foi iniciado, porém não foi concluído. Neste estado, é possível cancelar o processo e recuperar a imagem. Fonte: Elaborado pelo autor com base nas informações do Openstack (2012i). 3.4.4.2 Glance-registry O glance-registry é um serviço que efetua o mapeamento das imagens com os respectivos dispositivos de armazenamento. Ele condiciona as informações em um banco de dados SQLite ou MySQL. Openstack (2012i). 3.4.4.2 Formato de Discos e Containers As imagens enviadas para o Glance podem ser classificadas como formato de disco ou formato de container. O formato de disco de uma imagem é o mesmo do formato do disco original de onde ela foi produzida originalmente. Já o formato container, contém, além do disco original da máquina, um arquivo de metadados com informações sobre os requerimentos da máquina virtual, utilizado normalmente pelos hypervisors. Os quadros abaixo descrevem os tipos de imagens e containers suportados pelo OpenStack. Openstack (2012i). Quadro 5 - Tipos de imagens suportados pelo Glance. Formato Descrição raw Formato de imagem de disco não estruturado. vhd Formato de imagem padrão utilizado por VMWare, Xen, Microsoft, VirtualBox, e outros hypervisors. vmdk Outro formato padrão utilizado por diversos hypervisors. vdi Formato de imagem suportado pelos hypervisor VirtualBox e emulador QEMU.
    • 84 iso Formato de imagem que contém dados de um disco óptico (CDROM). qcow2 Formato de imagem de disco suportado pelo emulador QEMU que pode expandir dinamicamente e suportar "copy on write". aki Formato de imagem da Amazon AWS. O AKI (Amazon Kernel Image) é análogo à imagem do kernel, padrão do sistema Linux (vmlinuz). ari Formato de imagem da Amazon AWS. O ARI (Amazon Ramdisk Image) é análogo ao initrd/initramfs, responsável por ler os módulos iniciais do boot do sistema Linux. ami Formato de imagem da Amazon AWS. O AMI (Amazon Machine Image) contém módulos e a imagem do kernel Linux em um mesmo arquivo. Fonte: Elaborado pelo autor com base nas informações de Openstack (2012i). Quadro 6 - Tipos de containers suportados pelo Glance. Formato Descrição ovf O Open Virtualization Format é um formato aberto de imagem para ser utilizado por diferentes hypervisors. bare Indica que nenhum container ou metadados existe para esta imagem. aki Formato padrão da Amazon, que pode conter algumas pequenas informações na imagem. Ari Formato padrão da Amazon, que pode conter algumas pequenas informações na imagem. Ami Formato padrão da Amazon, que pode conter algumas pequenas informações na imagem. Fonte: Elaborado pelo autor com base nas informações de Openstack (2012i). 3.4.5 OpenStack Identity Service (Keystone) O Keystone realiza o controle de políticas de identidade e acesso para todos os componentes do OpenStack. Com o Keystone é possível realizar a autenticação de um usuário, garantindo que uma solicitação vem realmente de quem ele diz ser, e garantindo, também, a sua autorização, assegurando que ele terá acesso apenas aos serviços que está de fato solicitando. O Keystone possui sua própria API baseada no REST API, a Indentity API. Com ela todos os componentes do OpenStack, inclusive usuários, realizam a interação para autenticar e autorizar diversas ações. O Keystone Identity tem três principais funções: Openstack (2012e).
    • 85  gerenciamento de usuários: mantém cadastro de usuários autenticando e autorizando a realizarem ações;  serviço de Catálogo: Possui uma lista de serviços associados aos componentes do OpenStack e que estão à disposição dos usuários;  serviço de Políticas: Realiza o gerenciamento de serviços para o acesso específico de usuários e ou grupos. A autenticação de usuários no Keystone pode ser realizada de duas formas diferentes, baseado na utilização de usuário/senha ou através de um token48 . É importante citar, também, que alguns componentes do Keystone foram estabelecidos, conforme listados abaixo: Openstack (2012e).  endpoints: são considerados endpoints, cada componente do Openstack (Nova, Swift ou Glance) que está instalado em uma porta e um endereço dedicado;  regions: é definido como regions toda localização física dedicada em um datacenter, como um servidor ou centro de dados dedicado;  user: representação digital de um cliente de um serviço do OpenStack;  services: cada componente do Openstack (Nova, Swift, Glance, outros) que está conectado, ou sendo administrado pelo Keystone;  role: uma role é uma regra, ou conjunto de regras que podem ser associadas a diferentes usuários;  tenant: é um projeto, grupo ou a associação de regras e endpoints para um determinado usuário inquilino. A imagem a seguir exemplifica o fluxograma de uma solicitação de criação de serviço através de um usuário validado pelo Keystone. 48 Token – Chave eletrônica utilizada para autenticação.
    • 86 Figura 17 - Processo para criação de um serviço validado pelo Keystone. Fonte: Elaborado pelo autor com base em Openstack, (2012c) 3.4.5.1 Base de Dados O Keystone pode utilizar os serviços de banco de dados SQLite ou MySQL para armazenar informações de usuários e senhas, mas também pode utilizar uma base de LDAP (Lightweight Directory Access Protocol) existente. Openstack (2012e). 3.4.6 Openstack Administrative Web-Interface (Horizon) Horizon é um componente que disponibiliza um painel de administração de serviços do Openstack, através de uma interface web escrita em Python, conforme pode ser observado na imagem a seguir. Ele pode ser utilizado tanto para usuários finais que irão gerenciar apenas volumes e instâncias, como para o administrador do ambiente, que necessita de configurações avançadas do ambiente. A aplicação comunica-se com os demais componentes do OpenStack através de chamadas específicas de cada API, permitindo diversas ações entre usuários e os respectivos componentes. Disponibilizado para acesso ao púbico via protocolo HTTP pelo
    • 87 módulo mod_wsgi49 em conjunto com o Apache50 , fornece diversas funcionalidades, conforme seguem:  gerenciamento de instâncias: o Horizon possibilita a execução ou término de instâncias, o acesso de máquinas por VNC, o anexo de volumes, o uso de variáveis, entre outros;  acesso e Gestão de Segurança: possibilita a criação de grupos de segurança, par de chaves para acesso, atribuição de ips flutuantes, entre outros;  gerenciamento de perfis instâncias: possibilita criar e apagar modelos de máquinas virtuais;  gerenciamento de imagens: permite editar ou apagar imagens de máquinas virtuais;  gerenciamento de usuários: fornece meio para a criação de usuários, quotas e atribuições ao inquilino.  gerenciamento de volumes: suporte para criar volumes e fotos do estado de máquinas virtuais (snapshots);  manipulação do Object Store: possibilidade de criar e apagar containers e objetos. 49 Módulo que suporta a execução da linguagem Python. http://code.google.com/p/modwsgi/ 50 Aplicação para hospedagem de serviços web. http://httpd.apache.org
    • 88 Figura 18 - Tela de gerenciamento de instâncias do Horizon. Fonte: Editado pelo autor com base em Openstack (2012e). 3.5 ANÁLISE DO EUCALYPTUS E OPENSTACK Eucalyptus e OpenStack são soluções existentes com a proposta de fornecer um sistema capaz de orquestrar um ambiente para a nuvem. A melhor definição para descrever o Eucalyptus, é a afirmativa de ser uma plataforma IaaS que possibilita a criação de um projeto escalável de nuvem híbrida e/ou privada, utilizando a infraestrutura de TI existente nas próprias empresas. EUCALYPTUS SYSTEMS (2012a, pag. 4). Da mesma forma, segundo OPENSTACK (2012a), o OpenStack é um sistema que possibilita o fornecimento de serviços de IaaS em uma nuvem pública ou privada, utilizando código de software aberto. Para obter um melhor comparativo entre as duas plataformas e delinear quais as aplicabilidades de cada solução, um quadro comparativo entre os dois sistemas foi desenvolvido, apresentando as suas principais características. É importante ressaltar, que as informações do quadro a seguir foram retiradas da documentação oficial dos próprios sistemas. Entretanto, algumas características do Eucalytptus não foram localizadas na documentação oficial, que é um tanto vaga na descrição de seus componentes internos.
    • 89 Quadro 7 - Comparativo de características entre OpenStack e Eucalyptus. OpenStack Eucalyptus Tipo de Serviço IaaS IaaS Arquitetura Recomendada Público/Privado Privado Início Desenvolvimento 2010 2008 Licença Apache v2 Proprietário / GPLv3 Versão atual estável Essex V2.1 Armazenamento Persistente (EBS) Nova-volume Storage Controller (CC) Armazenamento Objetos (EC3) Swift Walrus Hypervisors Xen, XenServer, KVM, Qemu, Hyper-V, VMware, UML Xen, KVM, VMware API Própria e padrão euca2ools Padrão euca2tools Banco Dados MySQL, Postgress e SQLite Não localizado Drivers Autenticação LDAP/AD LDAP/AD Altorítmo de escalonamento Sim, nova-scheduler Sim Compatibilidade EC2/S3 Sim Sim Alta Disponibilidade Depende do componente Depende do componente Movimentação instâncias tempo real Sim Não localizado Configuração de rede para instâncias VLAN, DHCP, pelo sistema Estático, DHCP e VLAN Sistema Operacional Hospedeiro Ubuntu, RHEL, CentOS, Fedora Ubuntu, Fedora, CentOS, OpenSuse, Debian Principais participantes RackSpace, Nasa, Dell, HP, RedHat, IBM, Microsoft, etc. TrendMicro, Nasa, F5, NTT Data, Sony, Cloudera, etc. Linguagem Programação Python Java, C, Python Periodicidade de versões 6 meses Não definido Autenticação p/ conexão à instância Chaves SSH Chaves SSH Fonte: Criado pelo autor com base em Openstack (2012b), Openstack (2012c), Eucalyptus (2012a), Eucalyptus (2012b), Eucalyptus (2012c).
    • 90 4 PROJETO PRÁTICO E RESULTADOS OBTIDOS Este capítulo tem o intuito de apresentar o método e as técnicas que foram utilizados para a construção e elaboração da implantação. O estudo deste capítulo foi realizado utilizando métodos de pesquisa e métodos experimentais, dos quais foram utilizados para coletar dados e realizar análises do projeto implantado. A construção de uma pesquisa, de acordo com Prodanov (2003), requer uma série de regras visando a atingir um determinado conhecimento. Estas regras são necessárias para garantir ao trabalho científico um alto grau de confiabilidade, comprovação das afirmações realizadas e consequentemente conclusões baseadas em dados reais. A pesquisa experimental objetiva apresenta o modo ou as causas pelas quais um determinado fenômeno é produzido. Para atingir os resultados propostos, o pesquisador faz uso de instrumentos de verificação apropriados e capazes de tornar perceptíveis as relações existentes entre as variáveis envolvidas no objeto de estudo. Conforme Malhotra (2004, p. 217) pode-se caracterizar um experimento quando “o pesquisador manipula uma ou mais variáveis independentes, mede o seu efeito sobre uma ou mais variáveis dependentes ao mesmo tempo em que controla o efeito sobre variáveis estranhas”. A seguir, será apresentando a proposta do ambiente implantado, os métodos de coleta dos dados e a sua posterior análise. 4.1 AMBIENTE DA PROPOSTA DE TRABALHO A proposta do ambiente será utizar os componentes Nova e Glance do projeto OpenStack versão ESSEX, para prover uma infraestrutura necessária para a coleta e análise de dados. O Swift, componente para o armazenamento de objetos do OpenStack, não será implantado pela necessidade de ser instalado em um ambiente com maiores recursos computacionais. O ambiente utilizado, foi um computador Dell Inspiron 1525 da marca DELL51 , com 4GB de memória RAM e um processador CPU INTEL Core 2 DUO com 2.2GHZ, juntamente com o sistema operacional hospedeiro Ubuntu 11.10 64 bits e o 51 http://www.dell.com.br
    • 91 sistema de virtualização Virtualbox 4.1.6, duas máquinas virtuais foram instaladas para serem utilizadas como base para a instalação dos componentes do OpenStack. O Virtualbox será utilizado como a primeira camada de virtualização das máquinas na nuvem, por prover uma interface simples e intuitiva e por possuir uma ótima integração com o sistema operacional hospedeiro (Ubuntu 11.10). Este ambiente é melhor compreendido, na ilustração da imagem 19. 4.1.1 Requisitos da infraestrutura O quadro abaixo apresenta o ambiente necessário para a instalação da infraestrutura. É importante salientar, que as duas máquinas virtuais precisam ser instaladas com o sistema operacional Ubuntu 12.04, o qual tem a melhor compatibilidade com a versão atual do Openstack. Apesar da utilização do Ubuntu, o Openstack possibilita também a instalação em outros tipos de sistemas operacionais, de acordo com o apresentado no quadro 7. Quadro 8 - Requisitos dos servidores para a estrutura. cloud01 cloud02 Sistema Ubuntu Server 12.04 64 bits Ubuntu Server 12.04 64 bits Disco 20GB 20GB Memória 1.5GB 1GB Rede NAT eth0 (dhcp) eth0 (dhcp) Rede Pública eth1 (192.168.56.2) eth1 (192.168.56.3) Rede Privada eth2 (vlan) eth2 Fonte: Criado pelo autor. 4.1.2 Arquitetura do ambiente Conforme apresentado no quadro anterior, a estrutura proposta necessita de duas máquinas virtuais com o sistema operacional Ubuntu Server 64 bits e com três interfaces de rede para cada máquina. A primeira interface será utilizada para buscar os pacotes do Openstack na internet e manter as atualizações futuras. A segunda interface será utilizada para a comunicação entre os componentes do Openstack e para disponibilizar endereços ips flutuantes para as instâncias criadas. A terceira interface será utilizada para vincular interfaces virtuais (com VLAN) entre o nova-
    • 92 compute e as instâncias virtuais criadas. A criação das interfaces em VLAN será de responsabilidade do nova-compute, que as criará conforme a demanda. A imagem abaixo demonstra a arquitetura externa do ambiente, sem a inclusão detalhada dos componentes do Openstack. Embora não seja obrigatório, é recomendável que o processador possua suporte de virtualização por hardware, otimizando desta forma o ambiente a ser instalado. Figura 19 - Estrutura externa do ambiente proposto. Fonte: Criado pelo autor. A imagem a seguir, ilustra o ambiente instalado com uma visão direta para os componentes do OpenStack. Conforme é possível observar na ilustração citada, o primeiro servidor terá instalado todos os componentes do Openstack. Já o segundo servidor, terá apenas os componentes nova-compute e nova-network instalados, formando um ambiente conhecido como multi-node. Em um ambiente multi-node, mais de um host pode ser utilizado para instanciar máquinas. É importante ressaltar, que não existe obrigatoriedade na instalação do componente nova-network no segundo servidor, ele apenas será instalado desta forma por acreditar-se na melhora do desempenho da rede e por garantir uma redundância para o serviço nova- network, embora precise estar definido para tal ação. Outra característica relevante na imagem a seguir, é o fato de existir apenas o sistema Qemu para a função de hypervisor. Esta limitação ocorre no ambiente
    • 93 proposto, por não ser possível a execução de outro tipo de hypervisor além do Qemu, quando este mesmo hypervisor já estiver em execução sob um tipo de sistema de virtualização. Neste ambiente apresentado, o sistema de virtualização VirtualBox já utiliza os benefícios da virtualização assistida por hardware, que também é exigido para a utilização de outros sistemas como KVM, Xen, Vmware ESX, entre outros. Figura 20 - Estrutura externa do ambiente proposto. Fonte: Criado pelo autor. 4.1.3 Processo de Instalação Como o processo de instalação exige uma grande quantidade de ações e comandos a serem realizados, ele foi descrito integralmente no apêndice A deste trabalho.
    • 94 4.2 COLETA DE DADOS DO AMBIENTE Nesta sessão serão apresentados os testes realizados a fim de obter dados para a análise e compreensão dos resultados. Após a implantação do ambiente, duas instâncias virtuais idênticas foram criadas. Uma foi iniciada pelo nó cloud01 e outra foi iniciada pelo nó cloud02. Em seguida, testes e simulações de falhas nos serviços foram executados. 4.2.1 Testes de Latência de Rede X Testes de Troca de Tráfego Este teste buscou verificar a latência e a capacidade de troca de tráfego das instâncias gerenciadas pelo OpenStack. Para a captação destes dados, os utilitários iperf52 e ping53 foram utilizados de modo a mensurar a capacidade máxima de troca de tráfego e a latência para a comunicação com as instâncias. Em uma situação de trabalho normal (sem a utilização de recursos computacionais), foram disparados da máquina hospedeira Ubuntu 11.10 (aqui atuando como um cliente da instância) sessenta pacotes ICMP (Internet Control Message Protocol) em três diferentes momentos, para as duas instâncias em execução, sendo uma instância por vez. Da mesma forma, o iperf foi executado em três momentos distintos, como forma de obter a capacidade máxima de troca de tráfego entre a máquina hospedeira (cliente) e a instância executada. Em um segundo momento, os testes de latência e tráfego foram realizados concomitantemente nas duas máquinas virtuais, gerando novas informações para a coleta. 4.2.2 Testes de Leitura e Gravação de Dados Assim como nos testes de rede do OpenStack, coletados anteriormente, também foram realizados testes na gravação e leitura de dados nos discos locais das instâncias e no sistema de arquivos criado a partir de um volume do OpenStack. Utilizando o comando tiotest da suíte tiobench54 , foram executados testes de 52 Iperf – Utilitário para mediar a capacidade máxima de troca de tráfego entre dois pontos. http://sourceforge.net/projects/iperf 53 Ping – Utilitário que verifica o tempo de resposta da comunicação de rede entre dois pontos. 54 Tiobench – Utilitário para coleta de dados de desempenho de discos. http:// sourceforge.net/projects/tiobench
    • 95 gravação e leitura dos dados de forma sequencial e randômica. Um total de seis testes foram executados nas duas instâncias e nos seus respectivos volumes de forma isolada. Posteriormente, três testes foram também executados, porém de forma simultânea. Como saída, foram retornados valores de capacidade máxima de gravação e a latência total de cada operação. 4.2.3 Simulação de falhas nos serviços do Nova Com o ambiente do OpenStack instalado e em execução, o serviço nova- compute, nova-scheduler, nova-network, nova-volume, nova-compute, nova-network Iptables, MySQL, RabbitMQ, e o Keystone foram parados para simular um falha geral e obter dados sobre o comportamento do ambiente. Por meio do comando “nova-manage service list”, é possível observar o estado dos componentes do Nova, se ativo ou inativo, conforme quadro ilustrado abaixo. A simulação de parada de todos os serviços foi executada por meio dos seus respectivos scripts localizados em “”/etc/init.d/” do nó cloud01. Tabela 3 - Lista de serviços ativos e inativos do Nova. Binary Host Zone Status State Updated_At nova-compute cloud01 nova enabled XXX 10/06/2012 00:38:14 nova-scheduler cloud01 nova enabled :-) 10/06/2012 00:45:07 nova-network cloud01 nova enabled :-) 10/06/2012 00:45:07 nova-volume cloud01 nova enabled :-) 10/06/2012 00:45:07 nova-compute cloud02 nova enabled XXX 10/06/2012 00:44:11 nova-network cloud02 nova enabled :-) 10/06/2012 00:45:07 Fonte: Criado pelo ator. 4.3 ANÁLISE DOS DADOS OBTIDOS Nesta sessão, serão descritos os resultados obtidos a partir da análise dos dados coletados. 4.3.1 Da latência e desempenho da rede Após a coleta dos dados, foi realizado um cálculo aritmético de soma e média dos valores obtidos nos testes individuais e coletivos, resultando na tabela e gráfico
    • 96 ilustrados a seguir. Os valores de latência e taxa média são exibidos em segundos e Mbits, respectivamente. Percebe-se que o fator de uso simultâneo afeta outras instâncias executadas em uma mesma zona do OpenStack e que compartilha os mesmos recursos. Tabela 4 - Tabela do resultado da análise dos dados de rede. Sem tráfego Com tráfego Taxa Média (Mbits) Latência mínima (s) 1,073 1,378 Latência média (s) 9,206 29,102 Latência máxima (s) 48,779 265,039 Individual 16 Simultâneo 10,5 Fonte: Criado pelo ator. Figura 21 - Gráfico do resultado da análise dos dados de rede. Fonte: Criado pelo ator. 4.3.2 Da latência e velocidade das operações de disco Assim como nos testes de rede, após a coleta dos dados, foi realizado um cálculo aritmético de soma e média dos valores obtidos nos testes individuais e coletivos, resultando na tabela e gráfico ilustrados a seguir. Nesta análise, constam os comparativos de operações individuais na instância, operações individuais no
    • 97 volume e operações simultâneas (duas instâncias ao mesmo tempo). Com base nos valores apresentados e na interpretação do gráfico, é possível observar que o fator de uso simultâneo, descrito neste trabalho como “multi-inquilino” pode afetar os demais usuários na nuvem. Também pode-se observar, que as operações realizadas diretamente na instância do OpenStack, possuem um desempenho muito superior se comparado à operações realizadas diretamente no volume. É claro que, estes valores foram obtidos por meio de uma plataforma que não é dedicada para o serviço de armazenamento, e podem estar distorcidos frente à utilização de equipamentos especializados para o armazenamento de dados. Os valores de tempo e taxa são exibidos em segundos e MBytes, respectivamente. Já os valores de latência média, são apresentados em milissegundos. Tabela 5 - Valores de desempenho das operações de leitura e escrita. Teste Simples Instância Teste Simples Vol Teste Simultâneo Vol Tempo (s) Taxa (MB/s) Tempo (s) Taxa (MB/s) Tempo (s) Taxa (MB/s) Write 40MBs 2,59 15,63 22,20 3,20 32,50 1,44 Random Write 16 MBs 2,36 6,69 10,78 1,48 16,77 0,99 Read 40 MBs 0,31 123,07 1,83 25,42 3,00 22,19 Random Read 16 MBs 0,20 85,92 0,77 25,61 1,55 24,40 Média (ms) Máximo (ms) Média (ms) Máximo (ms) Média (ms) Máximo (ms) Latência Média 0,36 83,28 1,26 386,70 2,93 1992,80 Fonte: Criado pelo ator.
    • 98 Figura 22 - Gráfico de desempenho das operações de leitura e escrita. Fonte: Criado pelo ator. 4.3.3 Da análise da disponibilidade dos componentes A partir dos dados obtidos com a parada planejada dos serviços do OpenStack, e do estudo dos materiais disponibilizados pelo projeto OpenStack, uma análise foi realizada sobre cada componente do OpenStack. Por exemplo, ao parar o componente nova-compute, foram feitas verificações como: se instâncias eram afetadas, ou se a conectividade era interrompida, entre outros testes. Como o comportamento de cada componente é diferente, eles foram registrados, analisados e sumarizados em uma tabela que mede o fator de disponibilidade para cada serviço e que fazem parte diretamente ou indiretamente do Openstack. No quadro a seguir, é possível visualizar o estudo realizado. É possível verificar, que componentes como o Keystone e o Iptables que tem um alto grau de importância para a arquitetura do OpenStack. A tabela foi criada a partir da visão de cada componente sobre um determinado sujeito. Por exemplo, o impacto do Keystone sobre a ativação de uma nova instância é alto, em razão de ele ser um concentrador de risco, já que efetua a autenticação dos componentes do OpenStack.
    • 99 Quadro 9 - Gráfico de desempenho das operações de leitura e escrita. Disponibilidade Sistema Instância Ativa Nova Instância Volume ativo Novo Volume Openstack Objeto Impacto Total Keystone - Alto - Alto Alto Alto 12 Iptables Alto Alto - - Alto - 9 Virtualizador Alto Alto - - Baixo - 7 Nova-compute - Alto - Alto Alto - 6 Nova-network - Alto - - Alto - 6 Nova-api - Alto - Baixo Alto - 6 Nova-scheduler - Alto - Alto Alto - 6 Swift Proxy Server - - - - Alto Alto 6 RabbitMQ Server - Alto - Alto Alto - 6 MySQL - Alto - Alto Alto - 6 Iscsi Server - Baixo Alto Alto Médio - 6 Glance-api - Alto - - Baixo - 4 Glance-registry - Alto - - Baixo - 4 Nova-volume - Baixo - Alto Médio - 3 Swift Object Server - - - - Baixo Baixo 2 Swift Container Server - - - - Baixo Baixo 2 Swift Account Server - - - - Baixo Baixo 2 Horizon - Baixo - - Baixo - 2 Nova-objectserver - - - - Baixo - 1 Fonte: Criado pelo ator.
    • 100 5 CONCLUSÃO A Computação nas Nuvens é uma grande evolução na era da Tecnologia da Informação. O assunto ainda é muito recente, mas ao mesmo tempo cresce de forma acelerada, principalmente pela promessa de redução de custos com TI e melhoria nos serviços computacionais. Nos últimos anos, foi possível observar o crescimento dos conceitos de virtualização e armazenamento centralizado, que assim como a computação nas nuvens, carecia de maiores estudos e testes com as novas tecnologias. Neste momento, o que pode-se observar é grandes empresas esforçando-se ao máximo para oferecer, de alguma forma, serviços computacionais sob demanda. Dentro desta perspectiva, a computação nas nuvens deixa de ser uma promessa para ingressar na realidade atual dos usuários e corporações. Apesar do crescimento vertiginoso dos serviços prestados na nuvem, constatou-se que empresas e usuários ainda possuem insegurança quando o assunto é alocar informações confidenciais em um ambiente controlado por terceiros. Observou-se, que a utilização de serviços computacionais sob demanda, por parte de empresas, começa primeiramente com sistemas de menor criticidade. Ao longo do tempo, com o amadurecimento sobre os conceitos da nova tecnologia, as empresas acabam por hospedar na nuvem sistemas de maior criticidade. Pelo lado de usuários domésticos, percebeu-se que a utilização da tecnologia é inclusive maior que nas empresas, por meio da utilização de serviços já conceituados como o e-mail, a hospedagem de arquivos pessoais, fotos, músicas, entre outros. Se por um lado temos a utilização dos serviços por parte de consumidores, temos do outro lado os prestadores de serviços de nuvem, que necessitam de soluções para fornecer um serviço seguro, eficaz e com qualidade. Diante deste cenário, o objeto de estudo deste trabalho foi apresentar a conceituação sobre computação nas nuvens e buscar soluções que se propusessem a oferecer uma solução para o gerenciamento de uma infraestrutura computacional. Desta forma, o seguinte questionamento fora realizado na definição de pesquisa deste trabalho: é possível que uma plataforma de software aberto, no esforço de seus colaboradores mundiais, consiga apresentar uma solução segura e eficaz, que possa controlar e gerenciar a infraestrutura de diferentes soluções de virtualização e de
    • 101 armazenamento de forma a oferecer serviços de IaaS, além de agregar maior segurança para a computação nas nuvens? Durante a pesquisa, foi possível encontrar diversas soluções de infraestrutura de nuvem, mas com diferentes focos de trabalho. Enquanto que algumas soluções proprietárias são totalmente fechadas e possuem pouco suporte para a integração com outras plataformas, as soluções de código aberto apresentam grande integração com diferentes sistemas e demonstram grandes potenciais para o crescimento em um ambiente repleto de sistemas de diferentes fabricantes e arquiteturas. Como o foco desta pesquisa estava em buscar soluções de código aberto para o gerenciamento do ambiente na Nuvem, foram realizadas análises entre as soluções OpenStack e Eucalyptus. A partir da análise dos dados coletados, percebeu-se que o Eucalyptus é uma solução madura, com utilização por parte de grandes empresas e integra-se com sistemas de armazenamento e virtualização. Entretanto, o número reduzido de suporte para os sistemas de virtualização e a sua política interna de fornecer uma solução de código proprietário e outra de código aberto, tende a deixar o Eucalyptus em desvantagem se comparado diretamente com o OpenStack. Esta divisão acaba por afastar grandes corporações interessadas em participar do projeto, ou mesmo desenvolver integrações com a plataforma, principalmente pela razão de problemas com “vendor lock-in”. Entende-se, que pela diversidade de tipos de soluções computacionais que formam o entorno da nuvem, um sistema de código fechado não consegue acompanhar o ritmo acelerado do surgimento de novos sistemas, do qual precisará integrar-se posteriormente. O OpenStack surgiu a partir de um esforço de diversas corporações engajadas no desenvolvimento de uma nova solução para a nuvem e que estivessem alinhadas com as necessidades de todos os seus participantes. Por meio do experimento realizado e através da análise dos dados obtidos, percebe-se que o OpenStack é uma solução muito robusta e com uma grande capacidade de expansão horizontal, possibilitando que o investimento da infraestrutura ocorra conforme a demanda dos serviços que disponibiliza. Apesar das falhas encontradas na aplicação durante a fase de implantação e dos problemas de pontos únicos de falhas em sua estrutura do qual foram relatados, é totalmente
    • 102 possível que empresas utilizem o OpenStack como base para fornecer serviços de IaaS próprios. É importante mencionar, que no decorrer do trabalho, diversas dificuldades foram encontradas. A documentação do OpenStack é muito nova, e por vezes está desatualiza frente ao rápido desenvolvimento da aplicação. Por possuir uma arquitetura complexa, a falta de documentação ou a sua falta de atualização, acaba dificultando o entendimento dos seus conceitos e componentes. Também é possível relatar, a dificuldade encontrada em instalar o ambiente com poucos recursos tecnológicos disponíveis. Por esta razão, testes de análises de desempenho podem ter sido influenciados pela falta de isolamento entre as camadas da virtualização. Estes testes, poderiam ser mais apurados se estivessem em um ambiente de produção, com máquinas dedicadas para as tarefas do OpenStack e dos sistemas de virtualização. Espera-se que este trabalho, possa ser utilizado como fonte de estudo e inspiração para novos projetos de computação nas nuvens. Apesar dos estudos serem projetados em um ambiente de homologação, eles podem ser aproveitados para a utilização na implantação de sistemas de produção. Academicamente, esta pesquisa também poderá ser utilizada como inspiração para a realização de novos trabalhos. A partir da documentação aqui presente, um sistema de instalação automática do OpenStack poderia ser desenvolvido de forma a facilitar a sua propagação em uma rede heterogênea. Outro trabalho interessante, seria a realização de um estudo mais aprofundado no componente Swift, buscando propiciar um ambiente para o armazenamento de grandes volumes de dados, utilizando uma estrutura formada por meio de anéis distribuídos. Um terceira opção seria o desenvolvimento de um sistema operacional completo, utilizando uma plataforma de Linux e o OpenStack e que poderia ser utilizado por empresas que necessitam oferecer ou mesmo consumir serviços computacionais na nuvem. Por fim, um trabalho poderia ser desenvolvido buscando estudar a garantia da alta disponibilidade dos componentes do OpenStack.
    • 103 REFERÊNCIAS ABNT NBR ISO/IEC 27001:2005. Tecnologia da Informação – Técnicas de Segurança – Sistemas de gestão de segurança da informação - Requisitos. RIO DE JANEIRO: ABNT, 2006. ABNT NBR ISO/IEC 27002:2005. Tecnologia da Informação – Técnicas de Segurança – Código de Prática para a Gestão da Segurança da Informação. RIO DE JANEIRO: ABNT, 2005. AICPA. SAS 70. Disponível em: <http://sas70.com/sas70_overview.html>. Acesso em 06 mai 2012. AMAZON, AWS Cloud, 2011. Disponível em: http://aws.amazon.com/. Acesso em: 02/11/2011. AMAZON. EUCA2OOLS. 2012f. Disponível em <http://aws.amazon.com/pt/ebs/>. Acesso em 03 abr 2012. AMAZON. AWS. 2012c. Disponível em <http://aws.amazon.com/pt/>. Acesso em 03 abr 2012. AMAZON. EBS. 2012e. Disponível em <http://aws.amazon.com/pt/ebs/>. Acesso em 03 abr 2012. AMAZON. EC2. 2012a. Disponível em <http://aws.amazon.com/pt/ec2/>. Acesso em 03 abr 2012. AMAZON. History. 2012d. Disponível em <http://phx.corporate- ir.net/phoenix.zhtml?c=176060&p=irol-corporateTimeline>. Acesso em 03 abr 2012. AMAZON. S3. 2012b. Disponível em <http://aws.amazon.com/pt/s3/>. Acesso em 03 abr 2012. APACHE, Fundation. Apache License 2.0. Disponível em: <http://www.apache.org/licenses/LICENSE-2.0.html>. Acesso em 29 abr 2012. BLOKDIJK, Gerard; MENKEN, Ivanka. Virtualization Specialist Level Complete Certification Kit. Austrália, Emereo Publishin. 2009
    • 104 CACTUS. OPENSTACK COMPUTE ADMINISTRATION MANUAL. Disponível em: http://docs.openstack.org/cactus/openstack-compute/admin/content/example- installation-architecture.html. Acesso em: 01/11/2011. CLOUDSTACK. Disponível em: <http://www.citrix.com/English/ps2/products/product.asp?contentID=2314749>. Acesso em 29 abr 2012. CSA. Security Guidance v3.0. 2012b. Disponível em: <http://www.cloudsecurityalliance.org/guidance/csaguide.v3.0.pdf> Acesso em 14 mai 2012. CSA. Cloud Security Alliance. 2012a. Disponível em: http://cloudsecurityalliance.org/. Acesso em: 18/08/2011. CSA. Guia de Segurança 2.1 pt-br. 2012c. Disponível em: <https://cloudsecurityalliance.org/guidance/CSAGuidance-pt-BR.pdf>. Acesso em 14 mai 2012. DANJOU, Julien. OpenStack Swift eventual consistency analysis & bottlenecks. Disponível em <http://julien.danjou.info/blog/2012/openstack-swift-consistency- analysis>. Acesso em 30 abr 2012. DELGADO, Victor. Exploring the limits of cloud computing, Masters Thesis. Kungliga Tekniska Högskolan. Stockholm, Sweden, 2010. EUCALYPTUS SYSTEMS, Installation Guide. Goleta, CA, 2012c. Disponível em <http://www.eucalyptus.com/sites/all/files/docs/3.0/ig.pdf>. Acesso em 03 mai 2012. EUCALYPTUS SYSTEMS. Administration Guide. Goleta, CA, 2012a. Disponível em: <http://www.eucalyptus.com/docs/3.0/ag.pdf>. Acesso em: 22 mai. 2012. EUCALYPTUS SYSTEMS. Euca2ools. 2012g Disponível em: http://open.eucalyptus.com/wiki/Euca2oolsUsing. Acesso em: 08/12/2011. EUCALYPTUS SYSTEMS. Story. Goleta, CA, 2012d. Disponível em: <http://www.eucalyptus.com/about/story>. Acesso em 22 mai 2012. EUCALYPTUS SYSTEMS. The Open Source Cloud Platform. . Goleta, CA, 2012e Disponível em: http://open.eucalyptus.com/. Acesso em: 10/08/2011.
    • 105 EUCALYPTUS SYSTEMS. What Is. Goleta, CA, 2012b. Disponível em: <http://www.eucalyptus.com/learn/what-is-eucalyptus>. Acesso em: 22 mai. 2012. EUCALYPTUS SYSTEMS. Why. Goleta, CA, 2012f, Disponível em: <http://www.eucalyptus.com/learn/why-eucalyptus>. Acesso em 22 mai 2012. FSF. GPLv3. Disponível em: <http://gplv3.fsf.org>. Acesso em 29 abr 2012. GRANCE Timothy; MELL Peter. THE NIST DEFINITION OF CLOUD COMPUTING. Gaithersburg – USA. National Institute of Standards and Technology, 2011. Disponível em: <http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf>. Acesso em 01 mai 2012. GUTWIRTH, Serge; POULLET, Yves; HERT, Paul De; LEENES, Ronald. Computers, Privacy and Data Protection: An Element of Choice. London: Springer, 2011. IBM. Cloud Computing. Disponível em: http://www.ibm.com/developerworks/br/library/l-cloud-computing/. Acesso em: 08/12/2011. IDC. Blog IDC Exchange. Disponível em: <http://blogs.idc.com/ie/?p=922>. Acesso em 06 mai 2012. ISO IEC 27001. Disponível em: <http://www.iso27001security.com/html/27001.html>. Acesso em 06 mai 2012. KVM. 2012a. Disponível em: <http://www.linux-kvm.org/>. Acesso em 19 mai de 2012. KVM. Kernel-based Virtual Machine. 2012b. Disponível em: http://www.linux- kvm.org/. Acesso em: 20/08/2011. LAKATOS, Eva Maria; MARCONI, Marina de Andrade. Fundamentos da Metodologia Científica. São Paulo: Atlas, 1991. MALHOTRA, Naresh K. Pesquisa de Marketing – uma orientação aplicada. 4ª Ed. São Paulo: Artmed Editora, 2004.
    • 106 MATTOS, Diogo Menezes Ferrazani. Virtualização: VMWare e Xen. Rio de Janeiro, Disponível em: <http://www.gta.ufrj.br/grad/08_1/virtual/artigo.pdf>. Acesso em 17 mai 2012. MICHAELLIS, Moderno Dicionário da língua portuguesa. Disponível em: <http://michaelis.uol.com.br/moderno/portugues/>. Acesso em 21 mai 2012. MILLER, Michael. Cloud Computing: Web-Based Applications That Change the Way You Work and Collaborate Online. Indianapolis, Indiana: QUE, 2008 MIRANDA, Antonio Basílio; VIANA, Carlos Juliano Moura; HAEUSLER, Edward Hermann; LIFSCHITZ, Sérgio. Processamento de dados Semânticos na Cloud: um estudo de caso com o Protein World Database. ISSN 0103-9741[Monografias em Ciência da Computação]. RIO DE JANEIRO, 2011. NIMBUS, Nimbus Platform. 2012a. Disponível em: http://www.nimbusproject.org/. Acesso em: 05/12/2011. NIMBUS. Nimbus About. 2012b. Disponível em: <http://www.nimbusproject.org/about/>. Acesso em 22 mai 2012. NIMBUS. Nimbus Features. 2012c. Disponível em: <http://www.nimbusproject.org/docs/current/features.html> Acesso em 22 mai 2012. NURMI, D.; WOLSKI, R.; GRZEGORCZYK, C.; OBERTELLI, G.; SOMAN, S.; YOUSEFF, L.; ZAGORODNOV, D. "The eucalyptus open-source cloud- computing system" in Proceedings of the 2009 9th IEEE/ACM International Symposium on Cluster Computing and the Grid-Volume 00, 2009. OLIVEIRA, Rômulo Silva; CARISSIMI, Alexandre da Silva; TOSCANI, Simão Sirineo. Sistemas Operacionais - 4ª Edição. Bookman Editora, 2010 OPENNEBULA. The Open Source Toolkit for Data Center Virtualization. Disponível em: http://opennebula.org/. Acesso em: 21/08/2011. OPENNEBULA.ORG. 2012a. Disponível em: <http://opennebula.org/>. Acesso em 22 mai 2012. OPENNEBULA.ORG. About the OpenNebula.org Project. 2012b. Disponível em: <http://opennebula.org/about:about>. Acesso em 22 mai 2012.
    • 107 OPENSTACK. 2012a. Disponível em <http://openstack.org/>. Acesso em 01 abr 2012. OPENSTACK. Admin Guide Objectstorage. 2012d. Disponível em <http://docs.openstack.org/trunk/openstack-object-storage/admin/os-objectstorage- adminguide-trunk.pdf>. Acesso em 23 abr 2012. OPENSTACK. Admin Guide. 2012e. Disponível em <http://docs.openstack.org/trunk/openstack-compute/admin/bk-compute-adminguide- trunk.pdf>. Acesso em 01 mai 2012. OPENSTACK. Glance Admin Guide. 2012i. Disponível em <http://docs.openstack.org/diablo/openstack-image-service/admin/os-image- adminguide-diablo.pdf>. Acesso em 02 mar 2012. OPENSTACK. Glance Architecture. 2012h. Disponível em <http://glance.openstack.org/architecture.html>. Acesso em 24 mai 2012 OPENSTACK. Glance Cache. 2012j. Disponível em <http://glance.openstack.org/cache.html>. Acesso em 03 mai 2012. OPENSTACK. Glance OpenStack Imaging Service. 2012g. Disponível em: http://glance.openstack.org/. Acesso em: 07/12/2011. OPENSTACK. Install Guide. 2012f. Disponível em <http://docs.openstack.org/trunk/openstack-compute/install/openstack-install-guide- trunk.pdf>. Acesso em 24 abr 2012. OPENSTACK. Overview. 2012b. Disponível em <http://openstack.org/downloads/openstack-compute-datasheet.pdf>. Acesso em 01 abr 2012. OPENSTACK. Starter Guide Essex. 2012c, Disponível em <http://docs.openstack.org/essex/openstack-compute/starter/os-compute- starterguide-trunk.pdf>. Acesso em 24 abr 2012. OPENSTACK. Swift Storage Infrastructure. 2012l. Disponível em: http://swift.openstack.org/. Acesso em: 07/12/2011.
    • 108 PCI. STANDARDS DOCUMENTS. Disponível em: <https://www.pcisecuritystandards.org/security_standards/documents.php?document =pci_dss_v2-0#pci_dss_v2-0>. Acesso em 06 mai 2012. PRODANOV, Cleber Cristiano. Manual de Metodologia Científica. 3. ed. Novo Hamburgo: Feevale, 2003. QEMU. 2012b. Disponível em: <http://wiki.qemu.org/>. Acesso em 20 mai 2012. QEMU. INTERNALS. 2012a. Disponível em: <http://qemu.weilnetz.de/qemu- tech.html>. Acesso em 20 mai 2012. REESE, George. Cloud Application Architectures - Bulding Applications and Infrastructure in the Cloud. Sebastopol, CA: O’Reilly, 2009. RFC3720, ISCSI - Internet Small Computer Systems Interface. Disponível em: http://www.ietf.org/rfc/rfc3720.txt. Acesso em: 07/12/2011. RIAK, Wiki, Disponível em <http://wiki.basho.com/What-is-Riak%3F.html>. Acesso em 30 abr 2012. SACKS, David. Demystifying Storage Networking - DAS, SAN, NAS, NAS Gateways, Fibre Channel, and iSCSI. San Jose – California – USA. IBM Storage Networking, 2001. Disponível em: <http://www- 03.ibm.com/industries/ca/en/education/k12/technical/whitepapers/storagenetworking. pdf>. Acesso em 21 mai 2012. SCHUBERT, Lutz. Expert Group Report. The Future Of Cloud Computing. Disponível em: <http://cordis.europa.eu/fp7/ict/ssai/docs/cloud-report-final.pdf>. Acesso em 01 mai 2012. SEMPOLINSKI, Peter; THAIN, Douglas. A Comparison and Critique of Eucalyptus, OpenNebula and Nimbus. IEEE International Conference on Cloud Computing Technology and Science, University of Notre Dame (2010) Sosinsky, Barrie. Cloud Computing Bible. Indianapolis: Wiley Publishing, Inc.,2011. SOTOMA OR, Borja; MONTERO, Rub n S.; LLORENTE, Ignacio M.; FOSTER, Ian. An Open Source Solution for Virtual Infrastructure Management in Private and Hybrid Clouds. IEEE INTERNET COMPUTING, SPECIAL ISSUE ON CLOUD COMPUTING, 2009.
    • 109 SYMANTEC. Pesquisa sobre Situação de Cloud Computing: resultados da América Latina. Disponível em: <http://www.symantec.com/content/pt/br/enterprise/images/theme/state-of- cloud/State-of-Cloud-Report-LAM-PORT-FN.pdf>. Acesso em: 28 abr. 2012. TANENBAUM, Andrew S. Distributed Operating Systems. New Jersey: Prentice Hall, 1995. TAURION, Cezar; Cloud Computing - Computação em Nuvem: Transformando o mundo da tecnologia da Informação. Rio de Janeiro: Brasport, 2009. UBUNTU. Ubuntu Enterprise Cloud. 2012b. Disponível em: http://www.ubuntu.com/cloud/. Acesso em: 03/09/2011. UBUNTU. Ubuntu Server. 2012a. Disponível em: http://www.ubuntu.com/business/server/overview. Acesso em: 07/12/2011. VELTE, Anthony T.; VELTE, Toby J.; ELSENPETER, Robert. Cloud Computing: Computação em Nuvem - Uma abordagem prática. Rio de Janeiro: Alta Books, 2011. VIRTUALBOX, Disponível em <https://www.virtualbox.org/>. Acesso em 20 mai 2012. VMWARE. 2012c. Disponível em: <http://www.vmware.com>. Acesso em 20 mai 2012. VMWARE. ESX/ESXi. Disponível em: http://www.vmware.com/products/vsphere/esxi-and-esx/overview.html. Acesso em: 05/12/2011. VMWARE. VMware vSphere. 2012b. Disponível em: <http://www.vmware.com/br/products/datacenter-virtualization/vsphere>. Acesso em 20 mai 2012. VMware. VMware White Paper – Understanding Full Virtualization, Paravirtualization, and Hardware Assist. 2012a.Disponível em: <http://www.vmware.com/files/pdf/VMware_paravirtualization.pdf>. Acesso em 20 mai 2012.
    • 110 XEN. Disponível em: <http://www.xen.org/>. Acesso em 20 mai 2012
    • 111 APÊNDICE A Este apêndice irá demonstrar passo a passo como realizar a instalação dos componentes Nova e Glance do Openstack. Conforme a proposta da topologia, dois servidores serão instalados para prover o ambiente computacional da nuvem. Eles foram instalados em um ambiente multi-node, onde mais de um servidor participa de uma mesma zona, provendo um ambiente escalável. Este passo a passo foi baseado na documentação oficial do Openstack de nome OPENSTACK STARTER GUIDE, (2012), com algumas modificações realizadas pelo autor. Conforme quadro de requisitos, demonstrado anteriormente neste trabalho, será efetuado a instalação básica de dois servidores utilizando o sistema operacional Linux "Ubuntu 12.04 Precise Pangolin Server 64 Bits". Após o termino da instalação do sistema operacional, é necessário efetuar a configuração da rede do ambiente e a atualização dos pacotes do sistema operacional. Servidor cloud01 Configuração da rede e atualização de pacotes Inicialmente será realizado a configuração das interfaces de rede do servidor. É necessário abrir o arquivo de configuração das interfaces e efetuar a configuração. # nano -w /etc/network/interfaces #Interface para busca de pacotes na Internet auto eth0 iface eth0 inet dhcp # Interface Pública auto eth1 iface eth1 inet static address 192.168.56.2 netmask 255.255.255.0 network 192.168.56.0 broadcast 192.168.56.255
    • 112 # Interface Privada auto eth2 iface eth2 inet manual up ifconfig eth2 up Efetuar a reinicialização das interfaces de rede. # /etc/init.d/networking restart Com a configuração da rede finalizada, é necessário efetuar a atualização dos pacotes do sistema. # apt-get update # apt-get upgrade Instalação dos pacotes do OpenStack Após a configuração da rede e da atualização do sistema, é necessário efetuar a instalação de pacotes do OpenStack. Neste servidor, serão instalados todos os pacotes do componente Nova para administração do ambiente da nuvem e do Glance para armazenar e registrar o catálogo de imagens de máquinas virtuais. Além disso, também serão instalados os pacotes que são requisitos para o funcionamento adequado do projeto OpenStack. A seguir, será efetuado a instalação dos pacotes necessários com a utilização do utilitário apt-get. Durante a execução deste comando, será necessária uma interação com o usuário para informar a senha de root do banco de dados que será utilizada posteriormente. A senha nesta implantação também foi definida como root. Para implantações em ambientes de produção, é indispensável que as senhas de acesso utilizadas na configuração do Openstack sejam senhas fortes. apt-get install bridge-utils ntp mysql-server python-mysqldb keystone python-keystone python- keystoneclient glance glance-api glance-client glance-common glance-registry python-glance nova-api nova-cert nova-compute nova-compute-kvm nova-doc nova-network nova-objectstore nova-scheduler
    • 113 nova-volume rabbitmq-server novnc nova-consoleauth openstack-dashboard qemu lvm2 open-iscsi iscsitarget iscsitarget-dkms Servidor NTP A utilização de um servidor NTP (Network Time Protocol) é com o objetivo de garantir que todos os servidores do ambiente tenham o mesmo horário, buscando uma sincronização de troca de mensagens adequada. O servidor NTP estará configurado para efetuar a sincronização de horário utilizando um servidor externo e como redundância, a base da hora local do sistema. Editar a configuração do arquivo /etc/ntp.conf e adicionar as linhas a seguir. # nano -w /etc/ntp.conf server ntp.ubuntu.com server 127.127.1.0 fudge 127.127.1.0 stratum 10 Iniciar a execução do serviço. # /etc/init.d/ntp start Após a inicialização é necessário verificar se o horário e data estão corretos. # date Banco de Dados O sistema de banco de dados utilizado neste ambiente será o MySQL, embora outros bancos de dados possam ser utilizados. Este banco de dados será utilizado pelos componentes do Keystone, Nova e Glance do Openstack. Será necessário efetuar a instalação do banco, e a criação de usuários e bancos para os respectivos componentes. Utilizando a senha de root do banco de dados criada anteriormente, os bancos, usuários e permissões serão criados a seguir.
    • 114 Os comandos abaixo realizarão o cadastro do banco de nome “nova”, um usuário de nome novadbadmin, definirá uma senha de acesso e irá adicionar direitos de acesso deste usuário com seu respectivo banco. Edite o arquivo do mysql-server de modo que ele ouça em todos os ips do servidor. # sed -i 's/127.0.0.1/0.0.0.0/g' /etc/mysql/my.cnf Reinicie o serviço do banco de dados. # /etc/init.d/mysql restart # mysql -uroot -proot -e 'CREATE DATABASE nova;' # mysql -uroot -proot -e 'CREATE USER novadbadmin;' # mysql -uroot -proot -e "GRANT ALL PRIVILEGES ON nova.* TO 'novadbadmin'@'%';" # mysql -uroot -proot -e "SET PASSWORD FOR 'novadbadmin'@'%' = PASSWORD('senhanova');" Os comandos abaixo realizarão o cadastro do banco de nome glance, um usuário de nome glancedbadmin, definirá uma senha de acesso e irá adicionar direitos de acesso deste usuário com seu respectivo banco. # mysql -uroot -proot -e 'CREATE DATABASE glance;' # mysql -uroot -proot -e 'CREATE USER glancedbadmin;' # mysql -uroot -proot -e "GRANT ALL PRIVILEGES ON glance.* TO 'glancedbadmin'@'%';" # mysql -uroot -proot -e "SET PASSWORD FOR 'glancedbadmin'@'%' = PASSWORD('senhaGlance');" Os comandos abaixo realizarão o cadastro do banco de nome keystone, um usuário de nome keystonedbadmin, definirá uma senha de acesso e irá adicionar direitos de acesso deste usuário com seu respectivo banco. # mysql -uroot -proot -e 'CREATE DATABASE keystone;' # mysql -uroot -proot -e 'CREATE USER keystonedbadmin;'
    • 115 # mysql -uroot -proot -e "GRANT ALL PRIVILEGES ON keystone.* TO 'keystonedbadmin'@'%';" # mysql -uroot -proot -e "SET PASSWORD FOR 'keystonedbadmin'@'%' = PASSWORD('senhaKeystone');" Keystone Para a configuração do Keystone (instalado previamente pelo apt-get) será necessário algumas alterações no arquivo /etc/keystone/keystone.conf para posteriormente inicializar o serviço e criar as tabelas do banco de dados. Edite o arquivo de configuração do keystone e altere ou adicione as configurações conforme a seguir. # nano -w /etc/keystone/keystone.conf [DEFAULT] admin_token = admin [sql] connection = mysql://keystonedbadmin:senhaKeystone@192.168.56.2/keystone Reinicie o serviço do Keystone para utilizar as novas configurações. # /etc/init.d/keystone restart Instale o banco de dados do Keystone no servidor MySQL. # keystone-manage db_sync Após, exporte as variáveis a seguir para o sistema. Elas serão utilizadas para interação com o Keystone. Elas foram adicionadas no arquivo .bashrc, de modo que o usuário root do sistema sempre tenha estas variáveis definidas. # echo "###CONFIGURAÇÕES OPENSTACK" >> ~/.bashrc # echo "export SERVICE_ENDPOINT="http://localhost:35357/v2.0"" >> ~/.bashrc # echo "export SERVICE_TOKEN=admin" >> ~/.bashrc
    • 116 Após, atualize as variáveis. # source ~/.bashrc Por fim, é necessário criar os tenants, users e roles, services e endpoints do Keystone, que serão utilizados pelos demais projetos para realizarem a autenticação e autorização. Como a criação destes atributos pode gerar uma certa confusão, foi desenvolvido durante este trabalho um script para facilitar a criação dos atributos básicos para o correto funcionamento do Keystone. # nano -w /tmp/keystone_create.sh #!/bin/bash #DEFINIR IP SERVIDOR IP="192.168.56.2" REGION="unisinosVS" #CRIAR TENANTS keystone tenant-create --name admin keystone tenant-create --name service #CRIAR USERS keystone user-create --name admin --pass admin --email admin@unisinos.br keystone user-create --name nova --pass nova --email nova@unisinos.br keystone user-create --name glance --pass glance --email glance@unisinos.br keystone user-create --name swift --pass swift --email swift@unisinos.br #CRIAR ROLES keystone role-create --name admin keystone role-create --name Member #BUSCA OS IDS CRIADOS ANTERIORMENTE #TENANT TENANTID_ADMIN=`keystone tenant-list | grep admin | awk '{print $2}'` TENANTID_SERVICE=`keystone tenant-list | grep service | awk '{print $2}'`
    • 117 #USER USERID_ADMIN=`keystone user-list | grep admin | awk '{print $2}'` USERID_NOVA=`keystone user-list | grep nova | awk '{print $2}'` USERID_GLANCE=`keystone user-list | grep glance | awk '{print $2}'` USERID_SWIFT=`keystone user-list | grep swift | awk '{print $2}'` #ROLE ROLEID_ADMIN=`keystone role-list | grep admin | awk '{print $2}'` ROLEID_MEMBER=`keystone role-list | grep Member | awk '{print $2}'` #ADICIONA POLÍTICAS PARA O ADMIN keystone user-role-add --user $USERID_ADMIN --role $ROLEID_ADMIN --tenant_id $TENANTID_ADMIN #ADICIONA POLÍTICAS PARA OS RESPECTIVOS USUÁRIOS keystone user-role-add --user $USERID_NOVA --role $ROLEID_ADMIN --tenant_id $TENANTID_SERVICE keystone user-role-add --user $USERID_GLANCE --role $ROLEID_ADMIN --tenant_id $TENANTID_SERVICE keystone user-role-add --user $USERID_SWIFT --role $ROLEID_ADMIN --tenant_id $TENANTID_SERVICE #ADICIONA POLITICA PARA O MEMBRO ADMIN UTILIZADO PELO HORIZON E SWIFT keystone user-role-add --user $USERID_ADMIN --role $ROLEID_MEMBER --tenant_id $TENANTID_ADMIN #CRIAÇÃO DOS SERVIÇOS DE TODOS OS COMPONENTES DO OPENSTACK keystone service-create --name nova --type compute --description 'OpenStack Compute Service' keystone service-create --name volume --type volume --description 'OpenStack Volume Service' keystone service-create --name glance --type image --description 'OpenStack Image Service' keystone service-create --name swift --type object-store --description 'OpenStack Storage Service' keystone service-create --name keystone --type identity --description 'OpenStack Identity Service' keystone service-create --name ec2 --type ec2 --description 'EC2 Service' SERVICEID_NOVA=`keystone service-list | grep nova | awk '{print $2}'` SERVICEID_EC2=`keystone service-list | grep ec2 | awk '{print $2}'`
    • 118 SERVICEID_KEYSTONE=`keystone service-list | grep keystone | awk '{print $2}'` SERVICEID_SWIFT=`keystone service-list | grep swift | awk '{print $2}'` SERVICEID_VOLUME=`keystone service-list | grep volume | awk '{print $2}'` SERVICEID_GLANCE=`keystone service-list | grep glance | awk '{print $2}'` keystone endpoint-create --region $REGION --service_id $SERVICEID_NOVA --publicurl 'http://'$IP':8774/v2/$(tenant_id)s' --adminurl 'http://'$IP':8774/v2/$(tenant_id)s' --internalurl 'http://'$IP':8774/v2/$(tenant_id)s' keystone endpoint-create --region $REGION --service_id $SERVICEID_VOLUME --publicurl 'http://'$IP':8776/v1/$(tenant_id)s' --adminurl 'http://'$IP':8776/v1/$(tenant_id)s' --internalurl 'http://'$IP':8776/v1/$(tenant_id)s' keystone endpoint-create --region $REGION --service_id $SERVICEID_GLANCE --publicurl 'http://'$IP':9292/v1' --adminurl 'http://'$IP':9292/v1' --internalurl 'http://'$IP':9292/v1' keystone endpoint-create --region $REGION --service_id $SERVICEID_SWIFT --publicurl 'http://'$IP':8080/v1/AUTH_$(tenant_id)s' --adminurl 'http://'$IP':8080/v1' --internalurl 'http://'$IP':8080/v1/AUTH_$(tenant_id)s' keystone endpoint-create --region $REGION --service_id $SERVICEID_KEYSTONE -- publicurl http://$IP:5000/v2.0 --adminurl http://$IP:35357/v2.0 --internalurl http://$IP:5000/v2.0 keystone endpoint-create --region $REGION --service_id $SERVICEID_EC2 --publicurl http://$IP:8773/services/Cloud --adminurl http://$IP:8773/services/Admin --internalurl http://$IP:8773/services/Cloud Após a criação do arquivo, é necessário executá-lo. bash /tmp/tmp/keystone_create.sh Verifique se os endpoints foram criados corretamente. É provável que se uma lista de seis atributos for apresentada, o processo foi concluído com sucesso. # keystone endpoint-list Configuração do Glance Para a configuração do Glance (instalado previamente pelo apt-get) será necessário algumas alterações nos arquivos de configuração para posteriormente inicializar o serviço e criar as tabelas do banco de dados.
    • 119 Abra o arquivo /etc/glance/glance-api-paste.ini e edite as configurações abaixo no final do arquivo. # nano -w /etc/glance/glance-api-paste.ini admin_tenant_name = service admin_user = glance admin_password = glance Faça as mesmas alterações no final do arquivo /etc/glance/glance-registry- paste.ini. # nano -w /etc/glance/glance-registry-paste.ini. admin_tenant_name = service admin_user = glance admin_password = glance No arquivo /etc/glance/glance-registry.conf é necessário efetuar a configuração para definição do banco de dados e também é preciso configurar o Glance para que utilize a autenticação integrada com o Keystone. # nano -w /etc/glance/glance-registry.conf sql_connection = mysql://glancedbadmin:senhaGlance@192.168.56.2/glance [paste_deploy] flavor = keystone Faça as mesmas alterações no arquivo /etc/glance/glance-api.conf para utilização do serviço de autenticação do Keystone. # nano -w /etc/glance/glance-api.conf [paste_deploy] flavor = keystone
    • 120 Após a configuração dos arquivos do Glance, é necessário criar as tabelas do banco de dados. # glance-manage version_control 0 # glance-manage db_sync Por fim, os serviços precisam ser reinicializados. # /etc/init.d/glance-api restart # /etc/init.d/glance-registry restart Adicione as variáveis de autenticação do Glance para o arquivo .bashrc do usuário root. Assim com o Keystone, estas configurações serão realizadas para manter permanentemente as variáveis definidas. # echo "export SERVICE_TOKEN=admin" >> ~/.bashrc # echo "export OS_TENANT_NAME=admin" >> ~/.bashrc # echo "export OS_USERNAME=admin" >> ~/.bashrc # echo "export OS_PASSWORD=admin" >> ~/.bashrc # echo "export OS_AUTH_URL="http://localhost:5000/v2.0/"" >> ~/.bashrc # echo "export SERVICE_ENDPOINT=http://localhost:35357/v2.0" >> ~/.bashrc Após, leia as variáveis. # source ~/.bashrc Verifique ser o serviço está funcionando adequadamente. O retorno padrão do comando a seguir será 0, ou seja, este é o valor de retorno para o bash, quando corresponde a um retorno de sucesso. Na tela, nada será exibido. # glance index
    • 121 Instalação dos Componentes do Nova Para a configuração do Nova (instalado previamente pelo apt-get) será necessário algumas alterações nos arquivos de configuração para posteriormente inicializar o serviço e criar as tabelas do banco de dados. O Nova e todos os seus componentes utilizam basicamente um arquivo principal de configuração chamado nova.conf e alguns outros com configurações auxiliares. Para facilitar seu entendimento, a configuração do arquivo foi separada em pequenas divisões conforme cada respectivo componente. Editar o arquivo /etc/nova/nova.conf e configurá-lo conforme abaixo. # nano -w /etc/nova/nova.conf # GERAL --daemonize=1 --dhcpbridge=/usr/bin/nova-dhcpbridge --logdir=/var/log/nova --state_path=/var/lib/nova --verbose --libvirt_use_virtio_for_bridges --FAKE_subdomain=ec2 --state_path=/var/lib/nova --lock_path=/var/lock/nova --root_helper=sudo nova-rootwrap --zone_name=unisinosVS --node_availability_zone=unisinosVS --storage_availability_zone=unisinosVS --auth_strategy=keystone --enable_zone_routing --ajax_console_proxy_url=http://192.168.56.2:8000 --osapi_host=192.168.56.2 # NOVA-NETWORK --dhcpbridge_flagfile=/etc/nova/nova.conf
    • 122 --force_dhcp_release --fixed_range=10.1.0.0/16 --network_size=32 --num_networks=1 --public_interface=eth1 --auto_assign_floating_ip --vlan_start=100 --vlan_interface=eth2 # ABAIXO (PRECISA SER DIFERENTE PARA CADA NÓ) --routing_source_ip=192.168.56.2 # ABAIXO (PRECISA SER DIFERENTE PARA CADA NÓ) --my_ip=192.168.56.2 --send_arp_for_ha --network_manager=nova.network.manager.FlatDHCPManager # NOVA-COMPUTE --connection_type=libvirt --libvirt_type=qemu --multi_host --iscsi_ip_prefix=192.168. --iscsi_ip_address=192.168.56.2 --api_paste_config=/etc/nova/api-paste.ini --image_service=nova.image.glance.GlanceImageService --glance_api_servers=192.168.56.2:9292 # BANCO DE DADOS --sql_connection=mysql://novadbadmin:senhanova@192.168.56.2/nova # RABBITMQ --rabbit_host=192.168.56.2 # NOVA-API --ec2_host=192.168.56.2 --ec2_dmz_host=192.168.56.2 --ec2_url=http://192.168.56.2:8773/services/Cloud --s3_host=192.168.56.2 --s3_dmz=192.168.56.2 --keystone_ec2_url=http://192.168.56.2:5000/v2.0/ec2tokens --allow_admin_api
    • 123 # NO-VNC CONSOLE --novnc_enabled=true --novncproxy_base_url=http://192.168.56.2:6080/vnc_auto.html # ABAIXO (PRECISA SER DIFERENTE PARA CADA NÓ) --vncserver_proxyclient_address=192.168.56.2 # ABAIXO (PRECISA SER DIFERENTE PARA CADA NÓ) --vncserver_listen=192.168.56.2 --vncserver_host=0.0.0.0 # ABAIXO (PRECISA SER DIFERENTE PARA CADA NÓ) --vncproxy_url=http://192.168.56.2:6080 # NOVA-SCHEDULER --scheduler_driver=nova.scheduler.simple.SimpleScheduler # NOVA-VOLUMES --volume_group=nova-volumes Altere as configurações de dono e permissões da pasta /etc/nova e do arquivo /etc/nova/nova.conf. # chown -R nova:nova /etc/nova # chmod 644 /etc/nova/nova.conf Adicione ao final do arquivo /etc/nova/api-paste.ini as configurações de tenant do Nova. # nano -w /etc/nova/api-paste.ini admin_tenant_name = service admin_user = nova admin_password = nova Crie as tabelas do Nova no banco de dados. # nova-manage db sync
    • 124 Após, exporte as variáveis a seguir para o sistema. Elas serão utilizadas para a interação com o Nova. Elas foram adicionadas no arquivo .bashrc, de modo que o usuário root do sistema sempre tenha estas variáveis definidas. # echo "export OS_TENANT_NAME=admin" >> ~/.bashrc # echo "export OS_USERNAME=admin" >> ~/.bashrc # echo "export OS_PASSWORD=admin" >> ~/.bashrc # echo "export OS_AUTH_URL="http://localhost:5000/v2.0/"" >> ~/.bashrc É necessário criar uma rede privada que será destinada para as instâncias que serão iniciadas. O nova-network será responsável por alocar por DHCP os endereços privados para as respectivas máquinas. O comando abaixo irá criar um grupo de ips, disponibilizando 32 endereços privados utilizando uma interface bridge de nome br100 respectiva a uma VLAN de vinculada a interface eth2. # nova-manage network create private --fixed_range_v4=10.1.0.0/27 --num_networks=1 -- bridge=br100 --bridge_interface=eth2 --network_size=32 Agora será criado um grupo de ips flutuantes e que será atribuido para as instâncias como forma de comunicação com a rede pública (internet). Aqui é importante uma observação. Como a rede de administração do ambiente do OpenStack é a mesma da rede pública, deve-se tomar o cuidado para não atribuir uma lista de ips correspondente aos ips dos serviços, o que ocasionaria um conflito de ips e a falta de comunicação entre os nodes. O comando abaixo irá criar um total de 32 ips que será destinado para as instâncias a partir do endereço 192.168.56.64/27. nova-manage floating create --ip_range=192.168.56.64/27 --interface eth1 Após, atualize as variáveis. # source ~/.bashrc
    • 125 Instalação do Nova-Volumes Para disponibilizar um volume com dados permanentes para as instâncias, é necessário efetuar a configuração do nova-volume. Primeiramente, é necessário disponibilizar uma LVM para o servidor cloud01 que estiver com o serviço do nova- volume ativo. Este VG (Volume Group) terá o nome de nova-volumes conforme configuração estabelecida no arquivo nova.conf (--volume_group=nova-volumes). Com o volume criado, o nova-volume poderá criar vários LV (Logical Volume) com diferentes tamanhos e que serão vinculados a instâncias já existentes. Primeiramente é necessário ter um disco dedicado e criar uma partição do tipo LVM (código 8e do fdisk), após o volume pode ser criado e o serviço iscsitarget (utilizado para prover o acesso aos volumes lógicos) pode ser iniciado. Criar a partição do tipo LVM (tipo 8e) com o fdisk no disco /dev/sdb disponibilizado para o nova-volumes. # fdisk /dev/sdb A seguir é criado o volume na partição /dev/sdb1 # pvcreate /dev/sdb1 # vgcreate nova-volumes /dev/sdb1 Agora, é necessário efetuar a configuração do serviço ISCSI. Conforme estabelecido anteriormente, este nó irá realizar tarefas do nova controller, além do nova-compute, iniciando instâncias. Por esta razão, este nó irá prover não somente o serviço de iscsi como também será um cliente dele próprio. A seguir, é habilitado o serviço ISCSI no arquivo /etc/default/iscsitarget. # sed -i 's/false/true/g' /etc/default/iscsitarget Reinicie os serviços iscsitarget (prover serviço iscsi), o open-iscsi (cliente iscsi) e o nova-volume.
    • 126 # /etc/init.d/iscsitarget restart # /etc/init.d/open-iscsi restart # /etc/init.d/nova-volume restart Após todas as configurações realizadas, reinicialize todos os servidos do Openstack Nova. # sudo restart libvirt-bin; sudo restart nova-network; sudo restart nova-compute; sudo restart nova-api; sudo restart nova-objectstore; sudo restart nova-scheduler; sudo restart nova-volume; sudo restart nova-consoleauth; Por fim, verifique se todos os serviços estão ativos. # nova-manage service list Binary Host Zone Status State Updated_At nova-scheduler cloud01 unisinosVS enabled :-) 2012-05-10 20:51:51 nova-compute cloud01 unisinosVS enabled :-) 2012-05-10 20:51:42 nova-cert cloud01 unisinosVS enabled :-) 2012-05-10 20:52:28 nova-consoleauth cloud01 unisinosVS enabled :-) 2012-05-10 20:51:52 nova-volume cloud01 unisinosVS enabled :-) 2012-05-10 20:51:52 nova-network cloud01 unisinosVS enabled :-) 2012-05-10 20:51:54 Configuração do Horizon Dashboard Se tudo estiver funcionando corretamente, o dashboard já estará pronto para ser utilizado. Ele foi instalado pelo comando apt-get anteriormente. Através de um navegador, é possível acessar a interface web pelo endereço http://192.168.56.2/. O próximo passo é a instalação do segundo servidor. Para ser possível a sua posterior identificação, é necessário configurar o nome do segundo nó do qual será chamado de cloud02. # echo "192.168.56.3 cloud02" >> /etc/hosts
    • 127 Servidor cloud02 Configuração da Rede e atualização de pacotes Assim como no servidor cloud01, incialmente será realizado a configuração das interfaces de rede do servidor. Configure as interfaces de rede. # nano -w /etc/network/interfaces #Interface para busca de pacotes na Internet auto eth0 iface eth0 inet dhcp # Interface Pública auto eth1 iface eth1 inet static address 192.168.56.3 netmask 255.255.255.0 network 192.168.56.0 broadcast 192.168.56.255 # Interface Privada auto eth2 iface eth2 inet manual up ifconfig eth2 up Efetuar a reinicialização das interfaces de rede. # /etc/init.d/networking restart Com a configuração da rede finalizada, é necessário efetuar a atualização dos pacotes do sistema. # apt-get update # apt-get upgrade
    • 128 Instalação dos pacotes do OpenStack Após a configuração da rede e da atualização do sistema, é necessário efetuar a instalação de pacotes do OpenStack. Neste servidor, serão instalados apenas os pacotes do nova-compute e nova-network, já que ele irá apenas instanciar máquinas virtuais. Ainda assim, alguns pacotes que são requisitos para o funcionamento adequado do projeto OpenStack serão também instalados como o cliente iscsi, o cliente ntp e o emulador Qemu. # apt-get install bridge-utils ntp nova-compute nova-network qemu open-iscsi Instalação do Servidor NTP Agora é necessário sincronizar o horário com o servidor cloud01 de modo que ambos tenham o mesmo horário. Editar a configuração do arquivo /etc/ntp.conf e adicionar a linha a seguir. # nano -w /etc/ntp.conf server 192.168.56.2 Iniciar a execução do serviço. # /etc/init.d/ntp start Após a inicialização, é necessário verificar se o horário e data estão corretos e sincronizados com o servidor cloud01. # date Agora é necessário adicionar o nome do host do primeiro servidor na lista de hosts. Isso é necessário para que seja possível a identificação de ambos no gerenciamento do ambiente.
    • 129 # echo "192.168.56.2 cloud01" >> /etc/hosts Editar o arquivo /etc/nova/nova.conf e configurá-lo conforme abaixo. Ele é uma cópia do host cloud01, com pequenas modificações em alguns dos endereços ips, conforme abaixo. # nano -w /etc/nova/nova.conf # GERAL --daemonize=1 --dhcpbridge=/usr/bin/nova-dhcpbridge --logdir=/var/log/nova --state_path=/var/lib/nova --verbose --libvirt_use_virtio_for_bridges --FAKE_subdomain=ec2 --state_path=/var/lib/nova --lock_path=/var/lock/nova --root_helper=sudo nova-rootwrap --zone_name=unisinosVS --node_availability_zone=unisinosVS --storage_availability_zone=unisinosVS --auth_strategy=keystone --enable_zone_routing --ajax_console_proxy_url=http://192.168.56.2:8000 --osapi_host=192.168.56.2 # NOVA-NETWORK --dhcpbridge_flagfile=/etc/nova/nova.conf --force_dhcp_release --fixed_range=10.1.0.0/16 --network_size=32 --num_networks=1 --public_interface=eth1 --auto_assign_floating_ip --vlan_start=100 --vlan_interface=eth2 # ABAIXO (PRECISA SER DIFERENTE PARA CADA NÓ)
    • 130 --routing_source_ip=192.168.56.3 # ABAIXO (PRECISA SER DIFERENTE PARA CADA NÓ) --my_ip=192.168.56.3 --send_arp_for_ha --network_manager=nova.network.manager.FlatDHCPManager # NOVA-COMPUTE --connection_type=libvirt --libvirt_type=qemu --multi_host --iscsi_ip_prefix=192.168. --iscsi_ip_address=192.168.56.2 --api_paste_config=/etc/nova/api-paste.ini --image_service=nova.image.glance.GlanceImageService --glance_api_servers=192.168.56.2:9292 # BANCO DE DADOS --sql_connection=mysql://novadbadmin:senhanova@192.168.56.2/nova # RABBITMQ --rabbit_host=192.168.56.2 # NOVA-API --ec2_host=192.168.56.2 --ec2_dmz_host=192.168.56.2 --ec2_url=http://192.168.56.2:8773/services/Cloud --s3_host=192.168.56.2 --s3_dmz=192.168.56.2 --keystone_ec2_url=http://192.168.56.2:5000/v2.0/ec2tokens --allow_admin_api # NO-VNC CONSOLE --novnc_enabled=true --novncproxy_base_url=http://192.168.56.2:6080/vnc_auto.html # ABAIXO (PRECISA SER DIFERENTE PARA CADA NÓ) --vncserver_proxyclient_address=192.168.56.3 # ABAIXO (PRECISA SER DIFERENTE PARA CADA NÓ) --vncserver_listen=192.168.56.3 --vncserver_host=0.0.0.0 # ABAIXO (PRECISA SER DIFERENTE PARA CADA NÓ)
    • 131 --vncproxy_url=http://192.168.56.3:6080 # NOVA-SCHEDULER --scheduler_driver=nova.scheduler.simple.SimpleScheduler # NOVA-VOLUMES --volume_group=nova-volumes Reinicialize os serviços do nova-compute e nova-network. Neste momento este nó irá se integrar a zona de nome unisinosVS, juntamente com o nó cloud01. # /etc/init.d/nova-compute restart # /etc/init.d/nova-network restart Por fim, verifique se os componentes de todos os nós estão ativos. Quando o “State” estiver como “:-)" significa que o serviço está operante. Quando estiver como "XXX" significa que está fora do ar, e não pode ser consultado. # nova-manage service list Binary Host Zone Status State Updated_At nova-cert cloud01 unisinosVS enabled :-) 2012-05-10 22:03:29 nova-consoleauth cloud01 unisinosVS enabled :-) 2012-05-10 22:03:23 nova-console cloud01 unisinosVS enabled :-) 2012-05-10 22:03:21 nova-compute cloud01 unisinosVS enabled :-) 2012-05-10 22:03:24 nova-scheduler cloud01 unisinosVS enabled :-) 2012-05-10 22:03:24 nova-network cloud01 unisinosVS enabled :-) 2012-05-10 22:03:25 nova-volume cloud01 unisinosVS enabled :-) 2012-05-10 22:03:22 nova-compute cloud02 unisinosVS enabled :-) 2012-05-10 22:03:22 nova-network cloud02 unisinosVS enabled :-) 2012-05-10 22:03:25 Envio de imagens Com o ambiente totalmente instalado, é necessário enviar uma imagem de um sistema operacional, e que será utilizado posteriormente para iniciar uma nova instância. Para isso, os comandos do Glance, serão executados diretamente no terminal do servidor cloud01. Em função disto, é necessário baixar uma imagem do Ubuntu e que já está preparada para integrar-se com o ambiente do Openstack.
    • 132 Após o download estar concluído, a imagem pode ser descompactada e enviada para o Glance. # wget http://uec-images.ubuntu.com/releases/precise/release/ubuntu-12.04-server-cloudimg- amd64.tar.gz # tar –zxvf ubuntu-12.04-server-cloudimg-amd64.tar.gz Enviar a imagem de kernel AKI para o Glance. Essa imagem é responsável por iniciar o sistema pela primeira vez. #glance add name="precise-server-cloudimg-amd64-vmlinuz-virtual" is_public=true disk_format=aki container_format=aki architecture=x86_64 < precise-server-cloudimg-amd64-vmlinuz- virtual Verificar o identificador ID da imagem enviada com o comando “nova image- list”. # nova image-list Utilizando o identificador ID da imagem acima, enviar a imagem completa do sistema. Esta imagem é o sistema operacional instalado e pronto para ser utilizado. #glance add name="ubuntu-server-cloudimg-amd64-12.04" is_public=true disk_format=ami container_format=ami architecture=x86_64 kernel_id=7538d245-b991-4d5f-822f-c3b9694c9fc8 < precise-server-cloudimg-amd64.img Grupo de Segurança Antes de iniciar a máquina virtual, é necessário criar um grupo de segurança no OpenStack. Este grupo é responsável por liberar e encaminhar as solicitações dos protocolos TCP (Transmission Control Protocol), UDP (User Datagram Protocol) e ICMP (Internet Control Message Protocol). Será liberada a porta 22, onde será possível acessar remotamente por SSH (Secure Shell) e o protocolo ICMP (Internet Control Message Protocol), para que sejam possíveis testes de conectividade. O comando a seguir irá criar um grupo de nome “unisinos” e irá atribuir a este grupo, a porta 22 e o protocolo ICMP com as “flags” “-1” e “-1”.
    • 133 # nova secgroup-create unisinos "unisinos" # nova secgroup-add-rule unisinos tcp 22 22 0.0.0.0/0 # nova secgroup-add-rule unisinos icmp -1 -1 0.0.0.0/0 Criação de um par de chaves pública / privada Para iniciar a instância, é necessário primeiramente criar um par de chaves públicas / privadas, utilizado para iniciar a instância e posteriormente para acessar a instância pelo protoloco SSH. O comando chmod abaixo é utilizado para proteger o acesso à chave de usuários não autorizados. # nova keypair-add unisinos > unisinos.pem # chmod 600 test.pem Execução de uma instância Após a criação do grupo a instância poderá ser iniciada. Uma instância de nome “unisinos_vm01”, utilizando a imagem enviada anteriormente, será executada. É importante observar que a imagem será iniciada usando como referência uma máquina do tipo “m1.tiny”, utilizando o grupo de segurança criado anteriormente, de nome “unisinos” e um par de chaves de nome “unisinos”. # nova boot --image " ubuntu-server-cloudimg-amd64-12.04" --flavor m1.tiny --key_name unisinos --security_groups unisinos unisinos_vm01 Por fim, utilizando o comando “nova list”, é possível verificar informações das instâncias que estão sendo executadas nesta zona. # nova list +--------------------------------------+---------------+--------+-------------------------------+ | ID | Name | Status | Networks | +--------------------------------------+---------------+--------+-------------------------------+ | ec35e0eb-dc9e-4dac-a3f4-f596275012f9 | unisinos_vm01 | ACTIVE | vmnet=10.1.0.3, 192.168.56.67 | +--------------------------------------+---------------+--------+-------------------------------+ Criação de um novo volume de dados
    • 134 Conforme relatado anteriormente, o volume de dados é fornecido pelo nova- volume através de um serviço iscsi. O comando a seguir cria um novo volume de nome unisinos01 e com 1GB de espaço # nova volume-create --display_name unisinos01 1 Após o volume ser criado, é necessário vincular ele a uma instância em execução. O próximo passo é a inclusão do volume na instância executada anteriormente. Após, o volume pode ser acessado na instância virtual como um novo dispositivo de nome “/dev/vdb” # nova volume-attach ec35e0eb-dc9e-4dac-a3f4-f596275012f9 1 /dev/vdb Existe uma falha no OpenStack que por vezes não consegue disponibilizar um volume para um instância, pois não realiza o logon no serviço iscsi. Se um erro ocorrer, e não for possível vincular o volume, o comando a seguir efetua o login no iscsi e disponibiliza para que o nova-compute faça a busca pelo dispositivo fornecendo o volume para a instância. # iscsiadm -m node -T iqn.2010-10.org.openstack:volume-00000007 -p 192.168.56.2:3260 -- login Acessar e logar na máquina virtual Para acessar a instância criada, é necessário informar a chave pública criada anteriormente, utilizando-a para conectar-se na máquina pelo protocolo SSH. # ssh -i unisinos.pem ubuntu@192.168.56.1