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 ondemand 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.
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.
2
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 opensource 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
8
NIST - U.S. National Institute of Standards and Technology
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
Investimento de Capital
Despesas
Tempo de Provisionamento
Flexibilidade
Requisitos de Experiência Equipe
Confiança
TI Interna Serviços Tercerizados Computação nas Nuvens
Significante
Moderado
Insignificante
Moderado
Significante
Baseado na utilização
Significante
Moderado
Nenhum
Limitado
Moderado
Flexível
Significante
Limitado
Moderado
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
13
MTBF – Cálculo utilizado para verificar o período médio entre falhas de um determinado dispositivo.
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 IBM 15
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 VMware 18
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 paravirtualizados 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
20
INTEL - Empresa multinacional de tecnologia dos Estados Unidos da América.
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.
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.
23
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
Aberto
Público/Híbrido/Privado
OpenStack
IaaS
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
29
HTTP - Hypertext Transfer Protocol – Protocolo utilizado para comunicação de sites web.
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
Data
OpenStack Compute OpenStack Object Storage
Lançamento Lançamento versão
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
Banco de dados de plataforma aberta. http://www.postgresql.org
37
Tipo de sistema de banco de dados local - http://www.sqlite.org
36
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 novacompute, 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
AllHostsFilter
AvailabilityZoneFilter
ComputeFilter
CoreFilter
DifferentHostFilter
IsolatedHostsFilter
RamFilter
Descrição
Este filtro utiliza todos os hosts disponíveis do
nova-compute (host).
Filtra uma zona disponível.
Verifica se um host tem capacidade suficiente
para executar uma instância.
Verifica se há núcleos suficientes no host para
executar a instância.
Realiza uma verificação para executar uma
instância apenas em um host diferente de
determinadas instâncias já iniciadas.
Permite chavear algumas imagens para que
sejam iniciadas apenas em determinados hosts
e vice-versa.
Permite definir uma quantidade máxima de
RAM (em percentual) que uma instância pode
exceder de um host.
76
Ao contrário do "DifferentHostFilter", verifica
SameHostFilter
quais hosts executam determinadas instâncias,
para executar a próxima no mesmo host.
Efetua uma verificação do agendamento
SimpleCIDRAffinityFilter
baseado no endereço de subnet do IP do host.
Não é um filtro, mas uma função para adicionar
um peso na filtragem dos itens acima. Quanto
nova.scheduler.least_cost.com
menor o peso final dos hosts, maior a
pute_fill_first_cost_fn
probabilidade de ser utilizado para iniciar uma
instância.
nova.scheduler.least_cost.noo Função para igualar o peso de todos os hosts,
p_cost_fn
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
45
xattrs - Filesystems support extended attributes
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.
Os dados da imagem foram removidos, mas o Glance manteve a
informação sobre a imagem. Será removida em momento
deleted
oportuno.
Um processo para apagar a imagem foi iniciado, porém não foi
concluído. Neste estado, é possível cancelar o processo e
pending_delete 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
raw
vhd
vmdk
Descrição
Formato de imagem de disco não estruturado.
Formato de imagem padrão utilizado por VMWare, Xen,
Microsoft, VirtualBox, e outros hypervisors.
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
ari
ami
Formato de imagem da Amazon AWS. O AKI (Amazon Kernel
Image) é análogo à imagem do kernel, padrão do sistema Linux
(vmlinuz).
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.
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
ovf
bare
aki
Ari
Ami
Descrição
O Open Virtualization Format é um formato aberto de imagem
para ser utilizado por diferentes hypervisors.
Indica que nenhum container ou metadados existe para esta
imagem.
Formato padrão da Amazon, que pode conter algumas pequenas
informações na imagem.
Formato padrão da Amazon, que pode conter algumas pequenas
informações na imagem.
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.
Tipo de Serviço
Arquitetura Recomendada
Início Desenvolvimento
Licença
Versão atual estável
Armazenamento Persistente (EBS)
Armazenamento Objetos (EC3)
Hypervisors
API
Banco Dados
Drivers Autenticação
Altorítmo de escalonamento
Compatibilidade EC2/S3
Alta Disponibilidade
Movimentação instâncias tempo real
Configuração de rede para instâncias
Sistema Operacional Hospedeiro
Principais participantes
Linguagem Programação
Periodicidade de versões
Autenticação p/ conexão à instância
OpenStack
IaaS
Público/Privado
2010
Apache v2
Essex
Nova-volume
Swift
Xen, XenServer, KVM, Qemu,
Hyper-V, VMware, UML
Própria e padrão euca2ools
MySQL, Postgress e SQLite
LDAP/AD
Sim, nova-scheduler
Sim
Depende do componente
Sim
VLAN, DHCP, pelo sistema
Eucalyptus
IaaS
Privado
2008
Proprietário / GPLv3
V2.1
Storage Controller (CC)
Walrus
Xen, KVM, VMware
Padrão euca2tools
Não localizado
LDAP/AD
Sim
Sim
Depende do componente
Não localizado
Estático, DHCP e VLAN
Ubuntu, Fedora, CentOS,
Ubuntu, RHEL, CentOS, Fedora OpenSuse, Debian
RackSpace, Nasa, Dell, HP,
TrendMicro, Nasa, F5, NTT
RedHat, IBM, Microsoft, etc.
Data, Sony, Cloudera, etc.
Python
Java, C, Python
6 meses
Não definido
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
Sistema
Ubuntu Server 12.04 64 bits
Disco
20GB
Memória
1.5GB
Rede NAT
eth0 (dhcp)
Rede Pública eth1 (192.168.56.2)
Rede Privada eth2 (vlan)
Fonte: Criado pelo autor.
cloud02
Ubuntu Server 12.04 64 bits
20GB
1GB
eth0 (dhcp)
eth1 (192.168.56.3)
eth2
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 novanetwork, 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 novacompute, 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
nova-compute
nova-scheduler
nova-network
nova-volume
nova-compute
nova-network
Host
cloud01
cloud01
cloud01
cloud01
cloud02
cloud02
Zone
nova
nova
nova
nova
nova
nova
Status
enabled
enabled
enabled
enabled
enabled
enabled
State
XXX
:-)
:-)
:-)
XXX
:-)
Updated_At
10/06/2012
10/06/2012
10/06/2012
10/06/2012
10/06/2012
10/06/2012
00:38:14
00:45:07
00:45:07
00:45:07
00:44:11
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
Latência mínima (s)
1,073
1,378
Latência média (s)
9,206
29,102
48,779
265,039
Latência máxima (s)
Taxa Média (Mbits)
Individual
Simultâneo
16
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.
Write 40MBs
Random Write 16
MBs
Read 40 MBs
Random Read 16
MBs
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)
2,59
15,63
22,20
3,20
32,50
1,44
Média
(ms)
Latência Média
2,36
0,31
6,69
123,07
10,78
1,83
1,48
25,42
16,77
3,00
0,99
22,19
0,20
85,92
0,77
25,61
1,55
24,40
Máximo
Média
Máximo
Média
Máximo
(ms)
(ms)
(ms)
(ms)
(ms)
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
Instância
Nova
Volume
Novo
Sistema
Ativa
Instância
ativo
Volume Openstack Objeto
Keystone
Alto
Alto
Alto
Alto
Iptables
Alto
Alto
Alto
Virtualizador
Alto
Alto
Baixo
Nova-compute
Alto
Alto
Alto
Nova-network
Alto
Alto
Nova-api
Alto
Baixo
Alto
Nova-scheduler
Alto
Alto
Alto
Swift Proxy Server
Alto
Alto
RabbitMQ Server
Alto
Alto
Alto
MySQL
Alto
Alto
Alto
Iscsi Server
Baixo
Alto
Alto
Médio
Glance-api
Alto
Baixo
Glance-registry
Alto
Baixo
Nova-volume
Baixo
Alto
Médio
Swift Object Server
Baixo
Baixo
Swift Container Server
Baixo
Baixo
Swift Account Server
Baixo
Baixo
Horizon
Baixo
Baixo
Nova-objectserver
Baixo
-
Fonte: Criado pelo ator.
Impacto
Total
12
9
7
6
6
6
6
6
6
6
6
4
4
3
2
2
2
2
1
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.corporateir.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
<http://www.apache.org/licenses/LICENSE-2.0.html>. Acesso em 29 abr 2012.
em:
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/exampleinstallation-architecture.html. Acesso em: 01/11/2011.
CLOUDSTACK.
Disponível
<http://www.citrix.com/English/ps2/products/product.asp?contentID=2314749>.
Acesso em 29 abr 2012.
em:
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.
http://cloudsecurityalliance.org/. Acesso em: 18/08/2011.
Disponível
em:
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-consistencyanalysis>. 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
http://open.eucalyptus.com/wiki/Euca2oolsUsing. Acesso em: 08/12/2011.
em:
EUCALYPTUS SYSTEMS. Story. Goleta, CA, 2012d. Disponível
<http://www.eucalyptus.com/about/story>. Acesso em 22 mai 2012.
em:
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
<http://www.eucalyptus.com/learn/why-eucalyptus>. Acesso em 22 mai 2012.
em:
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
http://www.ibm.com/developerworks/br/library/l-cloud-computing/.
Acesso
08/12/2011.
em:
em:
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.linuxkvm.org/. Acesso em: 20/08/2011.
LAKATOS, Eva Maria; MARCONI, Marina de Andrade.
Metodologia Científica. São Paulo: Atlas, 1991.
Fundamentos da
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
<http://www.nimbusproject.org/about/>. Acesso em 22 mai 2012.
em:
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 cloudcomputing 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-objectstorageadminguide-trunk.pdf>. Acesso em 23 abr 2012.
OPENSTACK.
Admin
Guide.
2012e.
Disponível
em
<http://docs.openstack.org/trunk/openstack-compute/admin/bk-compute-adminguidetrunk.pdf>. Acesso em 01 mai 2012.
OPENSTACK.
Glance
Admin
Guide.
2012i.
Disponível
<http://docs.openstack.org/diablo/openstack-image-service/admin/os-imageadminguide-diablo.pdf>. Acesso em 02 mar 2012.
em
OPENSTACK.
Glance
Architecture.
2012h.
Disponível
<http://glance.openstack.org/architecture.html>. Acesso em 24 mai 2012
em
OPENSTACK.
Glance
Cache.
2012j.
Disponível
<http://glance.openstack.org/cache.html>. Acesso em 03 mai 2012.
em
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-guidetrunk.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
<http://docs.openstack.org/essex/openstack-compute/starter/os-computestarterguide-trunk.pdf>. Acesso em 24 abr 2012.
em
OPENSTACK.
Swift
Storage
Infrastructure.
http://swift.openstack.org/. Acesso em: 07/12/2011.
em:
2012l.
Disponível
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
tech.html>. Acesso em 20 mai 2012.
em:
<http://qemu.weilnetz.de/qemu-
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://www03.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-ofcloud/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.
http://www.ubuntu.com/cloud/. Acesso em: 03/09/2011.
Disponível
UBUNTU.
Ubuntu
Server.
2012a.
Disponível
http://www.ubuntu.com/business/server/overview. Acesso em: 07/12/2011.
em:
em:
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 pythonkeystoneclient 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:[email protected]/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 [email protected]
keystone user-create --name nova --pass nova --email [email protected]
keystone user-create --name glance --pass glance --email [email protected]
keystone user-create --name swift --pass swift --email [email protected]
#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-registrypaste.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:[email protected]/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:[email protected]/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 novavolume 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
unisinosVS
enabled
:-) 2012-05-10 20:51:42
nova-cert
cloud01
cloud01
nova-consoleauth cloud01
unisinosVS
unisinosVS
enabled
:-) 2012-05-10 20:52:28
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:[email protected]/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
nova-cert
cloud01
nova-consoleauth cloud01
nova-console
nova-compute
cloud01
Zone
Status
unisinosVS
unisinosVS
unisinosVS
State Updated_At
enabled
:-) 2012-05-10 22:03:29
enabled
enabled
:-) 2012-05-10 22:03:23
:-) 2012-05-10 22:03:21
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
nova-network
cloud02
cloud02
unisinosVS
unisinosVS
enabled
enabled
:-) 2012-05-10 22:03:22
:-) 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-cloudimgamd64.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-vmlinuzvirtual
Verificar o identificador ID da imagem enviada com o comando “nova imagelist”.
# 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 novavolume 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 [email protected]