Post on 02-Aug-2015
UNIVERSIDADE SALVADOR - UNIFACSCURSO DE CIÊNCIA DA COMPUTAÇÃO
Lipe Ribeiro Teixeira Silva
Análise comparativa de soluções de Computação
em Nuvem: avaliação de maturidade e perspectivas
Salvador
2012.1
Lipe Ribeiro Teixeira Silva
Análise comparativa de soluções deComputação em Nuvem: avaliação de
maturidade e perspectivas
Monografia apresentada à Coordenaçãodo Curso de Ciência da Computação daUniversidade Salvador - UNIFACS, comorequisito parcial para a obtenção do grau deBacharel em Ciência da Computação.
Orientador: Profo . Christian Guerreiro
Salvador
2012.1
RESUMO
A popularização da Internet a partir da década de 1990 e o crescimento do conceito relativoa virtualização propiciaram o momento oportuno para o desenvolvimento da Computação emNuvem. A ideia de ter acesso a informação a qualquer momento e de qualquer lugar e que os re-cursos sejam fornecidos de acordo com a demanda é bastante atraente para empresas de todos ostamanhos e segmentos, assim como para usuários finais. Atualmente não há uma especificaçãoaberta e sob a autoridade de um órgão normatizador, ou seja, não há um formato realmente pa-dronizado. Sendo assim, diversas instituições acadêmicas e não-acadêmicas têm trabalhado nodesenvolvimento de soluções de código aberto na nuvem. Este trabalho apresenta as soluçõesde código aberto mais populares para Computação em Nuvem. A atividade de pesquisa temcomo foco a análise das ferramentas OpenNebula, Eucalyptus (Elastic Utility Computing Ar-chitecture for Linking Your Programs To Useful Systems), openQRM (open Qlusters ResourceManager) e OpenStack, fazendo um comparativo de suas principais características.
Palavras-chave: Computação em Nuvem, Sistemas Distribuídos, Virtualização, ferramen-tas de código aberto, OpenNebula, Eucalyptus, openQRM, OpenStack.
ABSTRACT
The popularization of the Internet from the 1990s and the growth of the concept relatedto virtualization provided the best time to the development of Cloud Computing. The idea ofhaving access to information anytime and anywhere and that resources are provided accordingto demand is very attractive to companies of all sizes and segments, as well as for end users.Currently there is not an open specification under the authority of a standard-setting body, inother words, there is not actually a standardized format. In this way, various academic and no-nacademic have worked on developing open source solutions in the cloud. This paper presentsthe most popular open source solutions on Cloud Computing. The research activity have thefocus on the analysis of the tools OpenNebula, Eucalyptus, OpenQRM and OpenStack, makinga comparison of its main features.
Keywords: Cloud Computing, Distributed Systems, Virtualization, open source tools,OpenNebula, Eucalyptus, OpenQRM, OpenStack.
LISTA DE FIGURAS
1 Visão Geral - Nuvem Computacional (RUSCHEL; ZANOTTO; MOTA, 2010) . . . . 15
2 Sistema Distribuído Típico (TANENBAUM; STEEN, 2006) . . . . . . . . . . . . . 19
3 Arquitetura Eucalyptus (EUCALYPTUS, 2012b) . . . . . . . . . . . . . . . . . . 36
4 Sistema Modular OpenNebula (OPENNEBULA, 2012b) . . . . . . . . . . . . . . 45
5 Arquitetura OpenNebula (OPENNEBULA, 2012b) . . . . . . . . . . . . . . . . . 45
6 Processos OpenNebula (OPENNEBULA, 2012b) . . . . . . . . . . . . . . . . . . 46
7 Arquitetura libvirt (OPENNEBULA, 2012c) . . . . . . . . . . . . . . . . . . . . 48
8 Arquitetura openQRM (OPENQRM, 2012b) . . . . . . . . . . . . . . . . . . . . 52
9 Arquitetura OpenStack (OPENSTACK, 2012a) . . . . . . . . . . . . . . . . . . . 57
LISTA DE TABELAS
1 Descrição dos estados do serviço (EUCALYPTUS, 2012a) . . . . . . . . . . . . . 39
2 Relação Falha X Disponibilidade do sistema (EUCALYPTUS, 2012a) . . . . . . 41
3 Evolução Projeto OpenNebula (OPENNEBULA, 2012a) . . . . . . . . . . . . . . 44
4 Evolução Projeto openQRM (SOURCEFORGE, 2012) . . . . . . . . . . . . . . . 51
5 Evolução Projeto OpenStack (OPENSTACK, 2012b) . . . . . . . . . . . . . . . 56
6 Quadro Comparativo das Soluções . . . . . . . . . . . . . . . . . . . . . . . . 65
LISTA DE ABREVIATURAS E SIGLAS
3G 3rd Generation Mobile Telecommunications, p. 14
AMQP Advanced Message Queue Protocol, p. 56
API Application Programming Interface, p. 15
CaaS Communication as a Service, p. 26
CAGR Compound Annual Growth Rate, p. 17
CC Cluster Controller, p. 34
CLC Cloud Controller, p. 34
CPU Central Processing Unit, p. 14
DaaS Database as a Service, p. 25
DeaaS Development as a Service, p. 26
DHCP Dynamic Host Configuration Protocol, p. 61
DraaS Disaster Recovery as a Service, p. 27
DRBD Distributed Replicated Block Device, p. 48
EaaS Everything as a Service, p. 27
EAI Enterprise Application Integration, p. 22
EBS Elastic Block Store, p. 35
EC2 Elastic Compute Cloud, p. 34
ERP Enterprise Resource Planning, p. 24
HA High Availability, p. 40
HPC High Performance Computing, p. 34
HTTP Hypertext Transfer Protocol, p. 22
IaaS Infrastructure as a Service, p. 13
IBM International Business Machines, p. 22
ICMP Internet Control Message Protocol, p. 31
IDC International Data Corporation, p. 17
InaaS Information as a Service, p. 25
iSCSI Internet Small Computer System Interface, p. 35
ItaaS Integration as a Service, p. 26
LAN Local Area Network, p. 33
LDAP Lightweight Directory Access Protocol, p. 54
LTE Long Term Evolution, p. 14
LVM Logical Volume Manager, p. 47
LXC Linux Containers, p. 57
MaaS Management as a Service, p. 26
NAS Network-Attached Storage, p. 47
NASA National Aeronautics and Space Administration, p. 55
NAT Network Address Translation, p. 61
NC Node Controller, p. 34
NFS Network File System, p. 35
NNTP Network News Transfer Protocol, p. 31
NSF National Science Foundation, p. 34
NTT Nippon Telegraph and Telephone Corporation, p. 62
P2V Physical-to-Virtual, p. 50
PaaS Platform as a Service, p. 24
PDA Personal Digital Assistant, p. 16
PHP Hypertext Preprocessor, p. 50
POP3 Post Office Protocol 3, p. 31
PraaS Process as a Service, p. 26
QEMU Quick EMUlator, p. 57
QoS Quality of Service, p. 16
S3 Simple Storage Service, p. 34
SaaS Software as a Service, p. 23
SAN Storage Area Network, p. 35
SC Storage Controller, p. 34
SeaaS Security as a Service, p. 26
SLA Service Level Agreement, p. 16
SMTP Simple Mail Transport Protocol, p. 31
SNMP Simple Network Management Protocol, p. 31
SOAP Simple Object Access Protocol, p. 22
SSL Secure Socket Layer, p. 31
StaaS Storage as a Service, p. 25
TaaS Testing as a Service, p. 26
TCP Transmission Control Protocol, p. 21
TI Tecnologia da Informação, p. 14
UML User Mode Linux, p. 57
V2P Virtual-to-Physical, p. 50
V2V Virtual-to-Virtual, p. 50
VDI Virtual Desktop Infrastructure, p. 21
VGrADS Virtual Grid Application Development Software Project, p. 34
VLAN Virtual Local Area Network, p. 44
VMM Virtual Machine Manager, p. 30
XML Extensible Markup Language, p. 22
SUMÁRIO
1 Introdução 13
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 Computação em nuvem 14
2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Contexto Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Sistemas Distribuídos . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.3 Virtualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.4 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.5 TI Verde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4 Modelos de serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.4.1 Software como Serviço (SaaS) . . . . . . . . . . . . . . . . . . . . . . 23
2.4.2 Plataforma como Serviço (PaaS) . . . . . . . . . . . . . . . . . . . . . 24
2.4.3 Infraestrutura como Serviço (IaaS) . . . . . . . . . . . . . . . . . . . . 24
2.4.4 Outros modelos de serviço . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5 Modelos de implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5.1 Nuvem pública . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5.2 Nuvem privada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5.3 Nuvem comunitária . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5.4 Nuvem híbrida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3 Critérios 30
3.1 Sistemas de Virtualização Suportados . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Situação Atual do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 Soluções 33
4.1 Eucalyptus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.2 História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.3 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.4 Sistemas de Virtualização Suportados . . . . . . . . . . . . . . . . . . 36
4.1.5 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.6 Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.1.7 Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.1.8 Situação Atual do Projeto . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 OpenNebula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.2 História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.3 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.3.1 Front End . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.3.2 Host . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.3.3 Datastore . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.3.4 Service Network e VM Networks . . . . . . . . . . . . . . . 47
4.2.4 Sistemas de Virtualização Suportados . . . . . . . . . . . . . . . . . . 47
4.2.5 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.6 Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.7 Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.8 Situação Atual do Projeto . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3 openQRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.2 História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.3 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.3.4 Sistemas de Virtualização Suportados . . . . . . . . . . . . . . . . . . 52
4.3.5 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3.6 Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3.7 Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.3.8 Situação Atual do Projeto . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4 OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4.2 História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4.3 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.4.4 Sistemas de Virtualização Suportados . . . . . . . . . . . . . . . . . . 57
4.4.5 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.4.6 Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.4.7 Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4.8 Situação Atual do Projeto . . . . . . . . . . . . . . . . . . . . . . . . 62
5 Comparativo das Soluções 63
5.1 Sistemas de Virtualização Suportados . . . . . . . . . . . . . . . . . . . . . . 63
5.2 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3 Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.4 Alta Disponibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.5 Situação Atual do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.6 Quadro Comparativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6 Conclusão 66
6.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Referências 67
13
1 INTRODUÇÃO
1.1 MOTIVAÇÃO
A utilização da Computação em Nuvem está se tornando cada vez mais frequente. Dessa
forma, o gerenciamento da estrutura de nuvens virtuais é um campo a ser trabalhado devido à
falta de padronização e variedade de soluções hoje apresentadas.
Este trabalho apresenta um comparativo das principais características do OpenNebula, Eu-
calyptus, openQRM e OpenStack.
1.2 OBJETIVOS
Este trabalho objetiva fazer uma análise comparativa das ferramentas de código aberto
OpenNebula, Eucalyptus, openQRM e OpenStack, com foco no modelo de implementação de-
nominado IaaS (Infrastructure as a Service), conforme critérios estabelecidos no capítulo 3. A
pesquisa teve como base os sites oficiais das ferramentas, além de artigos e livros relacionados
com a área de pesquisa.
1.3 ESTRUTURA DO TRABALHO
Este trabalho encontra-se estruturado da seguinte forma: o capítulo 2 descreve a base teórica
necessária para entender os conceitos de Computação em Nuvem, modelos de serviço e de
implementação suportados; no capítulo 3 são apresentados os critérios que serão analisados
em cada um dos frameworks; no capítulo 4 são apresentadas as características básicas de cada
ferramenta, além da análise dos critérios adotados para comparação das soluções; no capítulo 5
é feito o comparativo entre todas as soluções para cada um dos critérios adotados anteriormente;
no capítulo 6 é apresentada uma conclusão sobre o trabalho, além de uma tabela resumo para
melhor visualização do mesmo e ainda há uma indicação do que poderá ser desenvolvido como
trabalhos futuros.
14
2 COMPUTAÇÃO EM NUVEM
2.1 INTRODUÇÃO
A constante queda no preço de laptops e smartphones, entre outros, além da facilidade do
acesso a Internet através das redes 3G (3rd Generation Mobile Telecommunications) e LTE
(Long Term Evolution) tem elevado o número de usuários conectados de forma constante nos
últimos anos. Com isso, tornou-se necessário fazer o gerenciamento de toda massa de dados
que circula nessas transações. Diante deste desafio, precisava-se desenvolver uma nova visão
para discutir possíveis soluções. Desta necessidade surgiu a Computação em Nuvem (Cloud
Computing).
O conceito de nuvem surge da disposição física dos elementos envolvidos no modelo. Os
recursos computacionais (como redes, servidores, armazenamento, aplicações e serviços) fi-
cam localizados em data centers de empresas de qualquer parte do mundo, o que nos leva a
necessidade de um termo que abstraia a localização. Dessa forma, adotou-se o termo nuvem.
Devido ao fato de permitir escalabilidade e elasticidade, o modelo oferece aos adminis-
tradores de TI (Tecnologia da Informação) uma maneira de aumentar a capacidade de acordo
com a demanda. Com a adoção do modelo, não existe a necessidade de alto investimento na
substituição de hardware obsoleto, na compra de licenciamento de softwares ou no treinamento
de pessoal, uma vez que todo o processamento se dá em servidores localizados nas nuvens,
pagando apenas pelos recursos utilizados do provedor (rede, armazenamento, memória, CPU
(Central Processing Unit), entre outros).
A convergência de uma gama de importantes tecnologias permite à computação na nuvem
prover serviços de forma transparente para o usuário, dentre outras funcionalidades e particula-
ridades.
As características essenciais são as vantagens que as soluções de computação em nuvem
oferecem. Em conjunto, algumas dessas características definem a computação em nuvem e
fazem a distinção com outros paradigmas. Abaixo veremos as cinco características essenciais
deste tipo de solução (VERAS, 2012):
15
Figura 1: Visão Geral - Nuvem Computacional (RUSCHEL; ZANOTTO; MOTA, 2010)
Elasticidade e Escalonamento: Recursos podem ser adquiridos de forma rápida e elás-
tica, em alguns casos automaticamente, caso haja a necessidade de escalar com o aumento da
demanda, e liberados, na retração dessa demanda. Para os usuários, os recursos disponíveis
para uso parecem ser ilimitados e podem ser adquiridos em qualquer quantidade e a qualquer
momento. A virtualização auxilia a elasticidade rápida na Computação em Nuvem, criando
várias instâncias de recursos requisitados utilizando um único recurso real [Aboulnaga et al.
2009]. Além disso, a virtualização é uma maneira de abstrair características físicas de uma pla-
taforma computacional dos usuários, exibindo outro hardware virtual e emulando um ou mais
ambientes que podem ser independentes ou não.
Self-Service Sob Demanda: O consumidor de serviços da computação na nuvem espera
adquirir recursos computacionais de acordo com sua necessidade e de forma instantânea. Para
suportar este tipo de expectativa, as nuvens devem permitir o acesso em auto-atendimento para
que os usuários possam solicitar, personalizar, pagar e usar os serviços desejados sem interven-
ção humana. O usuário pode adquirir unilateralmente recurso computacional, como tempo de
processamento no servidor ou armazenamento na rede, na medida em que necessite e sem pre-
cisar de interação humana com os provedores de cada serviço. O hardware e o software dentro
de uma nuvem podem ser automaticamente reconfigurados, orquestrados e estas modificações
são apresentadas de forma transparente para os usuários, que possuem perfis diferentes e assim
podem personalizar os seus ambientes computacionais, por exemplo, instalação de software e
configuração de rede para a definição de determinados privilégios.
Empresas que atuam na área de IaaS oferecem uma API (Application Programming Inter-
face) própria, que pode ser utilizada para a requisição dinâmica de recursos através de scripts
personalizados. A Computação em Nuvem não é mais que um modelo de prestação de servi-
ços. Neste tipo de computação, tudo o que pode oferecer um sistema de computação é fornecido
como um serviço.
16
Faturamento e Medição por uso: Uma vez que o usuário tem a opção de requisitar e uti-
lizar somente a quantidade de recursos e serviços que ele julgar necessário, os serviços devem
ser cobrados com base em um uso de baixa duração, como por exemplo, medido em horas de
uso. Os consumidores pagam aos provedores de serviço de nuvem de acordo com o consumo
efetuado (modelo de pagamento pelo uso semelhante a utilidades como energia e gás). Por esta
razão, as nuvens devem implementar recursos que garantam um eficiente comércio de serviços,
tais como tarifação adequada, contabilidade, faturamento, monitoramento e otimização do uso.
Esta medição de uso dos recursos deve ser feita de forma automática e de acordo com os dife-
rentes tipos de serviços oferecidos (armazenamento, processamento, largura de banda e contas
dos usuários ativas) e prontamente reportada, permitindo uma maior transparência comercial.
O uso de recursos pode ser monitorado e controlado, possibilitando transparência para o
provedor e o usuário do serviço utilizado. Para garantir a QoS (Quality of Service), pode-se
utilizar a abordagem baseada em SLA (Service Level Agreement). O SLA fornece informações
sobre os níveis de disponibilidade, funcionalidade, desempenho ou outros atributos do serviço
como o faturamento e até mesmo penalidades em caso de violação destes níveis.
Amplo acesso à rede: Os recursos devem estar disponíveis através da rede e acessados
através de mecanismos padrões que permitam a utilização dos mesmos por plataformas hetero-
gêneas, como smartphones, laptops, PDAs (Personal Digital Assistant), entre outros.
A interface de acesso a nuvem não obriga os usuários a mudarem suas condições e ambi-
entes de trabalho, como por exemplo, linguagens de programação e sistema operacional. Já os
softwares clientes instalados localmente para o acesso à nuvem são leves, como um navegador
de Internet.
Infraestrutura computacional, plataformas de desenvolvimento e aplicações são acessadas
via rede através de protocolos padrão. Isto possibilita a utilização dos serviços por máquinas
clientes que variam de desktops robustos a dispositivos móveis com severas limitações de re-
cursos. A Computação em Nuvem desenvolve a ideia da Internet com aplicações remotas.
Pooling de Recursos: No atendimento a múltiplos usuários verifica-se a grande dispari-
dade entre as necessidades dos mesmos, tornando essencial a capacidade de personalização dos
recursos da nuvem. Desde serviços de infraestrutura, a serviços de plataforma e serviços de
software.
Os recursos computacionais do provedor são organizados em um pool para servir múltiplos
usuários usando um modelo multi-tenant ou multi-inquilino, com diferentes recursos físicos e
virtuais, dinamicamente atribuídos e ajustados de acordo com a demanda dos usuários. Estes
17
usuários não precisam ter conhecimento da localização física dos recursos computacionais, po-
dendo somente especificar a localização em um nível mais alto de abstração, tais como o país,
estado ou centro de dados. Exemplos de recursos incluem o armazenamento, processamento,
memória, largura de banda de rede e máquinas virtuais.
2.2 CONTEXTO HISTÓRICO
Na década de 1980 Mark Weiser usou pela primeira vez o termo Computação Ubíqua para
descrever a onipresença da informática no cotidiano das pessoas. O conceito requer compu-
tadores pequenos, baratos e com tecnologias de ligação com ou sem fios a computadores de
maior dimensão. A partir de então, com a popularização da Internet na década de 1990 e o
rápido crescimento da produção e comercialização de dispositivos computacionais móveis, o
panorama tecnológico observado na atualidade começou a se formar. Com o aumento da co-
nectividade dos indivíduos, surgia, inteiramente on line, uma poderosa plataforma de serviços.
O conceito adotado por Mark Weiser se concretizou a partir do instante que a tecnologia passou
a ser inserida onde nunca havia sido imaginado.
No final da década de 1990, já com uma grande quantidade de serviços web disponíveis
e a necessidade de acessá-los através de dispositivos cada vez mais limitados, formava-se um
ambiente propício para o surgimento da Computação em Nuvem. Além disso, nesse mesmo
momento, crescia o conceito das tecnologias de virtualização de hardware para lidar com o
problema do consumo de recursos computacionais e com o desenvolvimento e utilização de
software. Sendo assim, a Computação em Nuvem é uma evolução tecnológica natural, não uma
nova tecnologia.
Pesquisa da IDC (International Data Corporation) mostra que a receita mundial de serviços
de TI em nuvem pública ultrapassou US$ 21,5 bilhões em 2010 e chegará a US$ 72,9 bilhões
em 2015, representando uma taxa composta de crescimento anual (CAGR (Compound Annual
Growth Rate) de 27,6%. Este rápido crescimento é mais de quatro vezes o crescimento pro-
jetado para o mercado de TI em todo o mundo como um todo (6,7%). Em 2015, um em cada
sete dólares gastos em pacotes de software, servidor e ofertas de armazenamento será através do
modelo de nuvem pública. Computação em Nuvem é um ingrediente essencial de uma trans-
formação maior da indústria de TI e muitas outras indústrias que usam a TI para se transformar.
Outros ingredientes ativados pela Computação em Nuvem incluem a explosão de aplicativos
móveis e a disponibilidade crescente de banda larga sem fio (WEB, 2012).
A grande vantagem na adoção da Computação em Nuvem é permitir utilizar os recursos
18
computacionais de forma mais econômica e otimizada, possibilitando uma redução de cus-
tos operacionais (menos hardware, manutenção simplificada, redução de gastos com ener-
gia e resfriamento, além do aluguel de espaço físico) e administrativo (contratando profissi-
onais) para manter sua própria infraestrutura, o que representa um fator extremamente relevante
considerando-se a redução de gastos com TI, além da tendência atual pela adesão a TI Verde.
Com a Computação em Nuvem estas empresas podem alugar a infraestrutura necessária de ou-
tras empresas que possuem enormes data centers (como a Amazon) e, com isso, conseguem
atingir economias de escala oferecendo tais serviços a um baixo custo a qualquer cliente.
2.3 ARQUITETURA
2.3.1 SISTEMAS DISTRIBUÍDOS
De acordo com o conceito de pooling de recursos e elasticidade e escalonamento, a Com-
putação em Nuvem é materializada num ambiente externo, composto por um data center que
comporta dados de diversas empresas de várias localidades, permitindo o aumento e diminuição
de recursos de acordo com a necessidade do cliente, ou seja, um ambiente capaz de oferecer
recursos virtualmente ilimitados e de forma “elástica”. O aspecto coletivo do funcionamento
destes data centers caracteriza o que é denominado um sistema computacional distribuído.
Um sistema distribuído é aquele que é definido como um conjunto de unidades de proces-
samento independentes, que através da troca de comunicação e gerenciamento de sincronização
pode processar uma aplicação em diferentes localidades em sistemas com características pró-
prias diferentes, dando a impressão ao usuário que toda a aplicação é gerenciada por um sistema
único. Temos o conceito de sincronização em um sistema centralizado e no sistema distribuído.
No sistema centralizado a sincronização é feita através do compartilhamento de áreas de memó-
ria, já no sistema distribuído ocorre a sincronização através da troca de mensagens. A aplicação
no sistema distribuído pode ser dividida em “partes” diferentes e ser processada em diversos
núcleos de processamento.
Assim, a computação distribuída consiste em adicionar o poder computacional de diversos
computadores interligados por uma rede de computadores. A união desses diversos computado-
res com o objetivo de compartilhar a execução de tarefas, é conhecida como sistema distribuído.
O objetivo é criar a ilusão que a aplicação (ou as aplicações) estão sendo processadas em
um único sistema, permitindo a sensação que tudo isso ocorre sem o compartilhamento de áreas
de memória, no entanto, a sincronização é feita a partir de trocas de mensagens. Faz parte do
19
objetivo a situação da aplicação ser processada de modo que o ambiente que opera forneça
situações favoráveis ao compartilhamento de recursos, sabendo que diferentes recursos estarão
disponíveis em unidades de processamento diferentes.
Em um sistema distribuído típico, a camada de middleware é composta pelo software res-
ponsável pelo provimento de uma interface de comunicação única e pela coordenação de usuá-
rios e aplicações para a utilização de máquinas distintas, cada uma com seu próprio sistema
operacional.
Figura 2: Sistema Distribuído Típico (TANENBAUM; STEEN, 2006)
Desta forma, o termo nuvem está diretamente relacionado a utilização de um grande sistema
distribuído.
2.3.2 MIDDLEWARE
Middleware é o neologismo criado para designar as camadas de software que não cons-
tituem diretamente aplicações, mas que facilitam o uso de ambientes ricos em tecnologia da
informação. A camada de middleware concentra serviços como acesso a bases de dados, men-
sagens, chamadas de procedimentos, monitoramento de transações, requisição de objetos, di-
retórios, ferramentas para segurança, entre outros. As aplicações tradicionais implementam
vários destes serviços, tratando-os de forma independente. Já as aplicações modernas delegam
e centralizam estes serviços na camada de middleware. Ou seja, o middleware atua como um
elemento que aglutina e dá coerência a um conjunto de aplicações e ambientes.
Apesar de suas limitações, todas as formas de middleware são úteis para facilitar a co-
municação entre diferentes aplicações. A seleção do middleware influencia na arquitetura da
aplicação, porque o middleware centraliza a infraestrutura do software e sua implantação. O
20
middleware introduz uma camada de abstração na arquitetura do sistema e assim reduz sua
complexidade consideravelmente. Por outro lado, cada produto de middleware introduz uma
sobrecarga de comunicação no sistema, que pode influenciar no desempenho, escalabilidade,
rendimento e outros fatores de eficiência. Isto deve ser levado em consideração no desenho
da arquitetura de integração, particularmente se os sistemas são críticos e são usados por um
grande número de usuários concorrentes (TANENBAUM; STEEN, 2006).
Os serviços de IaaS existentes atualmente funcionam através da utilização de interfaces de
web services oferecidas por estes middlewares, através das quais os clientes alocam recursos
contidos na infraestrutura do provedor.
2.3.3 VIRTUALIZAÇÃO
A virtualização é o processo de executar vários sistemas operacionais em um único equi-
pamento. Uma máquina virtual é um ambiente operacional completo que se comporta como
se fosse um computador independente. Com a virtualização, um servidor pode manter vários
sistemas operacionais em uso. Dentro do cenário tecnológico brasileiro, a virtualização vem ga-
nhando novas finalidades e atraindo aqueles que precisam realizar o “milagre da multiplicação”,
já que se trata de fazer caber mais informação em menor espaço físico.
Um conceito importante sobre virtualização é o do host (hospedeiro). O hospedeiro refere-
se a máquina na qual ocorrerá a virtualização, ou seja, o hardware físico onde o sistema ope-
racional é executado. Uma máquina na qual é feita a virtualização pode contar com apenas um
sistema operacional hospedeiro sendo executado por vez. No entanto, podem ser executados
diversos sistemas operacionais virtualizados (visitantes) simultaneamente.
As cinco principais vantagens do uso da virtualização são (VERAS, 2011):
Racionalização da manutenção: Reduzindo o número de servidores físicos é possível
cortar gastos de manutenção do hardware de forma relevante;
Melhor uso de recursos: Todo crescimento implica em aumento de gastos, mas quem
consegue fazer mais com menos certamente economiza energia elétrica, espaço, refrigeração e
administração;
Autonomia de aplicativos: Quando cada aplicativo está inserido em seu próprio servidor
virtual é possível evitar que upgrades e mudanças gerem impacto em toda rede e venham a
comprometer a rotina de trabalho;
Ganho de eficiência: A virtualização permite apresentar produtos, serviços e projetos ao
21
mercado com maior agilidade, já que é possível acessar desktops remotamente e com segurança;
Conformidade ideal: Várias tecnologias de sistemas operacionais podem coexistir em uma
única plataforma, ou seja, é possível haver sistemas Windows e Linux no mesmo servidor, o que
é uma grande vantagem para as empresas que vêm renovando sua infraestrutura de TI ao longo
dos anos.
As diferentes modalidades existentes de virtualização oferecem benefícios diversos, como
uma melhor utilização do sistema através do compartilhamento de recursos físicos, execução
de aplicações em ambientes isolados, eliminação de conflitos de domínio (como utilização das
mesmas portas TCP (Transmission Control Protocol), utilização simultânea de vários sistemas
operacionais em uma única máquina e isolamento de falhas. A seguir, são descritos os cinco
principais tipos de virtualização (VERAS, 2011):
Virtualização de Servidores: Técnica de execução de um ou mais servidores virtuais sobre
um servidor físico. Permite maior densidade de utilização de recursos (hardware, espaço e
etc), enquanto permite que isolamento e segurança sejam mantidos. Diferente da época dos
mainframes, a virtualização dos servidores agora acontece em servidores x86;
Virtualização de Desktops: Trata da configuração dos desktops dos usuários finais em uma
infraestrutura centralizada virtual. Isso significa que as aplicações de desktop também passam a
executar em um data center, sob a forma de máquinas virtuais. Este é o conceito de VDI (Vir-
tual Desktop Infrastructure), que permite a montagem dinâmica de desktops, oferecendo maior
confiabilidade e otimização do uso de espaço em disco com a consolidação do armazenamento e
flexibilidade na escolha do sistema operacional. Existem limitações para o uso desta técnica de
forma generalizada. Normalmente a sua adoção é antecedida por um trabalho de levantamento
da situação a ser considerada;
Virtualização do Armazenamento (Storage): A ideia é introduzir um componente (ap-
pliance) que permite que as diversas unidades heterogêneas de armazenamento (discos físicos)
sejam vistas como um conjunto homogêneo de recursos de armazenamento. A virtualização do
armazenamento não é tão popular quanto a virtualização de servidores;
Virtualização de Aplicações: Trata do conceito de execução do programa por completo,
em um repositório central, permitindo a configuração centralizada do aplicativo, o que melhora
seu gerenciamento, além de permitir que a configuração ou reconfiguração seja feita em um
único lugar;
Virtualização de Redes: Arquitetura que proporciona um ambiente de rede separado para
cada grupo ou organização. Estes ambientes lógicos são criados sobre uma única infraestrutura
22
compartilhada de rede. Cada rede lógica fornece ao grupo de usuários correspondente com
plenos serviços de rede, semelhantes aos utilizados por uma rede tradicional não virtualizada.
A experiência da perspectiva do usuário final é a de ter acesso a uma rede própria, com recursos
dedicados e políticas de segurança independentes. Assim, a virtualização da rede envolve a
lógica segmentação da rede de transportes, os dispositivos de rede, e todos os serviços de rede.
Devido às diversas redes lógicas compartilharem uma infraestrutura de rede comum, muitas
vezes centralizada e com um conjunto de equipamentos e servidores, os grupos de usuários
podem colaborar com maior flexibilidade e capacidade de gerenciamento. Esta colaboração
permite novos processos de negócio, que não seriam possíveis (e nem sequer imagináveis)
através de uma rede tradicional.
A virtualização é a peça chave para a construção de um ambiente com tais funcionalidades
de multi-arrendamento. O caráter “elástico” da nuvem com a provisão de recursos virtualmente
ilimitados, é obtido através da criação de novas instâncias de máquinas virtuais quando se faz
necessário, oferecendo ao cliente upgrades de recursos instantâneos e automatizados.
2.3.4 WEB SERVICES
Web Service é uma solução utilizada na integração de sistemas e na comunicação entre
aplicações diferentes. Com esta tecnologia é possível que novas aplicações possam interagir
com aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam
compatíveis.
Os Web Services são componentes que permitem às aplicações enviar e receber dados em
formato XML (Extensible Markup Language). O acesso sempre será via HTTP (Hypertext
Transfer Protocol), mas internamente existe uma string XML que está empacotada em um pro-
tocolo SOAP (Simple Object Access Protocol).
De acordo com a (MICROSOFT, 2006), SOAP é um padrão aberto criado pela Microsoft,
Ariba e IBM (International Business Machines) para padronizar a transferência de dados em
diversas aplicações, por isso, se dá em XML.
Essencialmente, o Web Service faz com que os recursos da aplicação do software estejam
disponíveis sobre a rede de uma forma normalizada. Existe uma grande motivação sobre a tec-
nologia Web Service, pois possibilita que diferentes aplicações comuniquem entre si e utilizem
recursos diferentes.
O objetivo dos Web Services é a comunicação de aplicações através da Internet. Esta co-
municação é realizada com intuito de facilitar a EAI (Enterprise Application Integration), que
23
significa a integração das aplicações de uma empresa, ou seja, interoperabilidade entre a infor-
mação que circula numa organização nas diferentes aplicações como, por exemplo, o comércio
eletrônico com os seus clientes e seus fornecedores.
A Computação em Nuvem torna possível a utilização de infraestrutura de hardware e soft-
ware remotamente, oferecendo-os como serviços aos usuários finais. Isto é possível devido à
utilização de interfaces de Web Services, através das quais requisições são traduzidas para o
processamento por parte dos servidores de gerenciamento dos provedores, que administram o
provimento de recursos de acordo com suas políticas internas de segurança e SLA estabelecidos
com seus clientes.
2.3.5 TI VERDE
TI Verde ou Green IT, ou ainda, Tecnologia da Informação Verde é uma tendência mundial
voltada para o impacto dos recursos tecnológicos no meio ambiente. A preocupação dessa
tendência está desde a utilização mais eficiente de energia, recursos e insumos na produção
de tecnologia, assim como no uso de matéria prima e substâncias menos tóxicas na fabricação
(SLB, 2009).
Além disso, abrange recursos tecnológicos que consumam menos energia, que não agridam
o meio ambiente na sua utilização e por fim não proporcione ou minimize impactos no seu
descarte, permitindo reciclagem e reutilização.
Sendo assim, a Computação em Nuvem e a virtualização em it data centers são classificadas
como tecnologias verdes, pois contribuem para a redução do consumo de energia e das emissões
de dióxido de carbono.
2.4 MODELOS DE SERVIÇO
2.4.1 SOFTWARE COMO SERVIÇO (SAAS)
A abordagem do SaaS (Software as a Service) tem o potencial de transformar a forma com
que os departamentos de tecnologia da informação relacionam-se e, até mesmo, o que pensam
sobre o seu papel como provedores de serviços para o restante da empresa. O surgimento do
SaaS como um mecanismo de entrega de software cria uma oportunidade para que os depar-
tamentos de TI alterem o seu enfoque: de implantar e dar suporte aos aplicativos a gerenciar
os serviços que esses aplicativos oferecem. Por sua vez, um departamento de TI centralizado
24
em serviço, bem-sucedido, produz mais valor para o negócio, diretamente, ao fornecer serviços
desenhados a partir de fontes internas e externas, e se alinhados com os objetivos corporativos
(IBM, 2011c).
Nesse modelo, as empresas deixam de comprar licenças e passam a ser “assinantes” dos
softwares, que são acessados pela Internet. Nas pequenas e médias empresas, por exemplo,
o novo modelo vai permitir acesso a softwares que antes eram quase proibitivos, devido ao
custo inicial (licença e hardware) e de manutenção (versões e suporte), como no caso dos atuais
softwares de gestão empresarial (ERP) (Enterprise Resource Planning).
2.4.2 PLATAFORMA COMO SERVIÇO (PAAS)
PaaS (Platform as a Service) é frequentemente a classificação mais confusa da computação
em nuvem, pois pode ser difícil de identificar, frequentemente sendo confundida com IaaS ou
com SaaS. O fator de definição que torna PaaS exclusiva é que permite que desenvolvedores de-
senvolvam e implementem aplicativos da Web em uma infraestrutura hospedada, ou seja, PaaS
permite aproveitar os recursos de computação aparentemente infinitos de uma infraestrutura de
nuvem (IBM, 2011b).
Outra grande vantagem da PaaS é a produtividade. O simples fato de não haver necessi-
dade de ficar projetando balanceamento de carga, replicação, cluster, instalando e configurando
middlewares (servidores de aplicação, banco de dados, etc.) já é um grande ganho. Além disso,
os grandes fornecedores estão criando uma camada de componentes prontos para uso, APIs e
aceleradores de desenvolvimento nessas plataformas, para cada vez mais acelerar o desenvolvi-
mento, como é o caso do Google App Engine e do Force.com (Salesforce).
2.4.3 INFRAESTRUTURA COMO SERVIÇO (IAAS)
IaaS refere-se ao fornecimento de infraestrutura computacional (geralmente em ambientes
virtualizados) como um serviço. Ao invés de se comprar novos servidores e equipamentos de
rede, quando necessário a ampliação de serviços são aproveitados os recursos ociosos disponí-
veis e é provisionado novos servidores virtuais à infraestrutura existente de maneira dinâmica.
Os meios não precisam ser comprados se podemos comprar somente os serviços de infor-
mações de que a organização necessita. Não estamos falando de terceirização ou de locação de
infraestrutura, estamos falando na aquisição de serviços de informação, ou seja, da aquisição do
produto final gerado por toda a infraestrutura de TI e não dos meios para gerá-lo (IBM, 2011a).
25
Em conformidade com as cinco características principais da Computação em Nuvem, o mo-
delo de IaaS fornece infraestrutura de forma dinâmica, automatizada e inerentemente escalável.
Com isto, o cliente do serviço pode aumentar ou diminuir a quantidade de recursos alocados
para si de acordo com sua necessidade. Ao abrir mão de uma infraestrutura própria através da
adesão ao IaaS, uma organização vê muitos de seus dados ultrapassarem seus domínios, sendo
armazenados na nuvem, um ambiente sobre o poder administrativo de terceiros. Dessa forma
muitas questões relacionadas à segurança da informação são levantadas, sendo este um dos
principais pontos de discussão do campo da Computação em Nuvem.
2.4.4 OUTROS MODELOS DE SERVIÇO
A variedade de serviços disponíveis em uma nuvem faz com que sua classificação seja
extendida a todo tempo. Outras nomenclaturas são encontradas com relativa facilidade no
mercado. Todavia, a estrutura da Computação em Nuvem é visivelmente formada pelas três
camadas fundamentais expostas nos subitens anteriores.
Atualmente, este tipo de classificação é amplamente aceito na literatura, pois engloba
grande parte dos subtipos encontrados e define suas funcionalidades de forma coerente e con-
cisa.
À medida que a computação em nuvem ganha força, muito se discute sobre como defini-la
em termos de modelo de computação. Alternativas de maturidade foram publicadas e debatidas,
e os fornecedores têm um modelo para seus próprios produtos.
Abaixo foram listadas outras categorias de tecnologia de Computação em Nuvem além das
principais já apresentadas (COMPUTERWORLD, 2010):
Armazenamento como Serviço (StaaS) (Storage as a Service): Como o nome indica,
é a capacidade de utilizar o storage que existe fisicamente em um site remoto, mas é, um re-
curso para qualquer aplicativo que requer armazenamento. É o componente mais primitivo da
computação em nuvem, explorado pela maioria dos outros;
Banco de Dados como Serviço (DaaS) (Database as a Service): Capacidade de utilizar os
serviços de um banco de dados hospedado remotamente, compartilhando-o com outros usuá-
rios. Funcionaria logicamente como se o banco de dados fosse local. Diversos fornecedores
oferecem diferentes modelos, mas sua força está em explorar a tecnologia de banco de dados
que normalmente custaria milhares de dólares em hardware e licenças de software;
Informação como Serviço (InaaS) (Information as a Service): Capacidade de consumir
26
qualquer tipo de informação, hospedada remotamente, por meio de uma interface bem definida,
como uma API;
Processo como Serviço (PraaS) (Process as a Service): Recurso remoto que pode reunir
muitos outros, tais como serviços e dados, sejam eles hospedados no mesmo recurso de Com-
putação em Nuvem ou remotamente, para criar processos de negócio. É possível pensar em
um processo de negócio como um aplicativo que abrange sistemas, explorando serviços e in-
formações essenciais que são combinados em sequência para formar processos. Em geral, eles
são mais fáceis de mudar do que os aplicativos, proporcionando agilidade a quem utiliza estes
mecanismos de processos fornecidos sob demanda;
Integração como Serviço (ItaaS) (Integration as a Service): Capacidade de fornecer uma
pilha de integração completa a partir da nuvem, incluindo interface com aplicativos, mediação
semântica, controle de fluxos, design de integração e assim por diante. Em essência, a inte-
gração como serviço abrange a maioria dos recursos e das funções encontradas na tecnologia
convencional de EAI, mas fornecidos como um serviço;
Segurança como Serviço (SeaaS) (Security as a Service): Capacidade de fornecer servi-
ços de segurança essenciais remotamente, via Internet. A maior parte dos serviços de segurança
disponíveis é rudimentar, porém alguns mais sofisticados, tais como gerenciamento de identi-
dade, começam a ser oferecidos;
Gestão como Serviço (MaaS) (Management as a Service): Qualquer serviço sob de-
manda que permita gerenciar um ou mais serviços de Computação em Nuvem, como geren-
ciamento de tempo de atividade, topologia, utilização de recursos e virtualização. Também
começam a surgir sistemas de governança, como capacidade de aplicar políticas definidas para
dados e serviços;
Teste como Serviço (TaaS) (Testing as a Service): Capacidade de testar sistemas locais
ou fornecidos em nuvem empregando software e serviços de teste hospedados remotamente.
É importante observar que, embora um serviço de nuvem exija teste em si mesmo, os siste-
mas de teste como serviço podem verificar outros aplicativos em nuvem, web sites e sistemas
empresariais internos, e não requerem espaço para hardware ou software na corporação;
Desenvolvimento como Serviço (DeaaS) (Development as a Service): As ferramentas de
desenvolvimento tomam forma na Computação em Nuvem como ferramentas compartilhadas,
ferramentas de desenvolvimento web-based e serviços baseados em mashup;
Comunicação como Serviço (CaaS) (Communication as a Service): Uso de uma solução
de comunicação unificada hospedada em data center do provedor ou fabricante;
27
Tudo como Serviço (EaaS) (Everything as a Service): Quando se utiliza tudo, infraestru-
rura, plataformas, software, suporte, enfim, o que envolve TIC como um Serviço;
Recuperação de Desastres como Serviço (DraaS) (Disaster Recovery as a Service): Re-
curso aplicado em uma nuvem privada ou usado em conjunto com um serviço de nuvem pública
para proteger dados e aplicativos em execução nestas nuvens. Nestes locais o acompanhamento
dos níveis de temperatura e umidade é muito importante.
2.5 MODELOS DE IMPLEMENTAÇÃO
No modelo de implementação, dependemos das necessidades das aplicações que serão im-
plementadas. A restrição ou abertura de acesso depende do processo de negócios, do tipo de
informação e do nível de visão desejado. Percebemos que certas organizações não desejam que
todos os usuários possam acessar e utilizar determinados recursos no seu ambiente de compu-
tação em nuvem. Surge assim, a necessidade de ambientes mais restritos, onde somente alguns
usuários devidamente autorizados possam utilizar os serviços providos. Os modelos de imple-
mentação da Computação em Nuvem podem ser divididos em: Privado, Público, Comunidade
e Híbrido (UFRJ, 2009).
2.5.1 NUVEM PÚBLICA
As nuvens públicas são aquelas que são executadas por terceiros. As aplicações de diversos
usuários ficam misturadas nos sistemas de armazenamento, o que pode parecer ineficiente a
princípio. Porém, se a implementação de uma nuvem pública considera questões fundamentais,
como desempenho e segurança, a existência de outras aplicações sendo executadas na mesma
nuvem permanece transparente tanto para os prestadores de serviços como para os usuários.
Um dos benefícios das nuvens públicas é que elas podem ser muito maiores do que uma
nuvem privada, por exemplo, já que elas permitem uma maior escalabilidade dos recursos. Essa
característica evita a compra de equipamentos adicionais para resolver alguma necessidade tem-
porária, deslocando os riscos de infraestrutura para os prestadores de infraestrutura da nuvem.
Há ainda a possibilidade de destinar algumas porções da nuvem pública para o uso exclusivo de
um único usuário, criando o chamado data center privado virtual, que provê a esse usuário uma
maior visibilidade de toda a infraestrutura.
Para este modelo de implantação as restrições de acessos não podem ser aplicadas, quanto
ao gerenciamento de redes, a aplicação de técnicas de autenticação e autorização também não
28
será possível. Na nuvem pública, a infraestrutura é disponibilizada para o público em geral,
sendo acessado por qualquer usuário que conheça a localização do serviço.
2.5.2 NUVEM PRIVADA
As nuvens privadas são aquelas construídas exclusivamente para um único usuário (uma
empresa, por exemplo). Diferentemente de um data center privado virtual, a infraestrutura
utilizada pertence ao usuário, e, portanto, ele possui total controle sobre como as aplicações são
implementadas na nuvem. Uma nuvem privada é, em geral, construída sobre um data center
privado.
Caso o usuário queira aumentar os recursos utilizados em sua nuvem privada, ele deve
adquirir novos equipamentos, como sistemas de armazenamento, por exemplo, já que a sua
nuvem está limitada à capacidade de seu sistema físico. Em uma nuvem pública, como já foi
falado anteriormente, não há essa necessidade, uma vez que, como os recursos são facilmente
escaláveis, basta o usuário reservar uma quantidade maior deles. Devido a essas diferenças,
diz-se que as nuvens públicas são mais adequadas para aplicações temporárias, enquanto que
as nuvens privadas são um ambiente mais apropriado a aplicações permanentes que demandam
níveis específicos de qualidade de serviço e de localização dos dados.
Para esse modelo de implantação são empregados políticas de acesso aos serviços. Ge-
renciamento de redes, configurações dos provedores de serviços e a utilização de tecnologias
de autenticação e autorização são as principais características deste modelo, que é mais caro,
porém garante uma maior segurança.
2.5.3 NUVEM COMUNITÁRIA
O modelo comunidade é caracterizado pelo fato da infraestrutura de nuvem ser compar-
tilhada por várias organizações e suporta uma comunidade específica que partilha as mesmas
preocupações como missão, requisitos de segurança, política e considerações de conformidade.
Pode ser gerenciado pelas organizações ou por terceiros e podem existir localmente ou remota-
mente.
2.5.4 NUVEM HÍBRIDA
A infraestrutura de nuvem híbrida é uma composição de duas ou mais nuvens (privado,
comunidade ou público) que permanecem entidades únicas, mas são unidos por proprietárias
29
de tecnologia padronizada que permite a portabilidade dos dados e aplicações.
As nuvens híbridas combinam os modelos das nuvens públicas e privadas. Elas permitem
que uma nuvem privada possa ter seus recursos ampliados a partir de uma reserva de recursos
em uma nuvem pública. Essa característica possui a vantagem de manter os níveis de serviço
mesmo que haja flutuações rápidas na necessidade dos recursos. A conexão entre as nuvens
pública e privada pode ser usada até mesmo em tarefas periódicas que são mais facilmente
implementadas nas nuvens públicas, por exemplo. O termo “computação em ondas” é, em
geral, utilizado quando se refere às nuvens híbridas.
É válido destacar que as nuvens híbridas introduzem a complexidade de determinar a ma-
neira como as aplicações são distribuídas entre nuvens públicas e privadas. A relação entre os
dados e os recursos de processamento, por exemplo, deve ser considerada. Se uma aplicação
possui uma grande quantidade de dados, o seu processamento em uma nuvem pública pode não
ser favorável, já que passar esses dados de sua nuvem privada para uma nuvem pública pode ser
muito custoso.
30
3 CRITÉRIOS
Este capítulo descreve detalhadamente os critérios adotados para a comparação entre as
soluções apresentadas neste trabalho. Os itens são apresentados individualmente para melhor
entendimento.
3.1 SISTEMAS DE VIRTUALIZAÇÃO SUPORTADOS
Nuvens computacionais são compostas, em sua maioria, por conjuntos de máquinas vir-
tuais. Sendo assim, os frameworks para Computação em Nuvem que operam a nível de IaaS
devem possuir a capacidade de gerenciar essas máquinas. Atualmente, encontramos vários sis-
temas que implementam a virtualização. Nesse contexto, um bom framework de IaaS deve
prover suporte eficaz ao maior conjunto de sistemas que implementam a virtualização, aumen-
tando assim seu escopo de trabalho.
Um exemplo de sistema de virtualização é o Hypervisor (ou VMM (Virtual Machine Ma-
nager)), dispositivo de software entre o hardware e o sistema operacional que é responsável
por fornecer a abstração da máquina virtual. Além disso, o VMM permite o funcionamento e
gerência de diversos sistemas operacionais alocados sobre uma mesma estrutura física (CPU,
memória , etc). O vSphere, da VMware, é um exemplo de hypervisor utilizado atualmente. Esse
tópico trata da enumeração dos sistemas de virtualização suportados por cada uma das soluções
apresentadas.
3.2 BACKUP
Nesta seção será tratada como cada uma das soluções lida com uma das principais ques-
tões da área de TI, o backup. O backup é muito valorizado por quem já perdeu informações
importantes e não teve possibilidade de as recuperar. Portanto, é um procedimento altamente
recomendável devido a frequência com que se perde informação digital, seja por ações despro-
positadas do usuário ou mau funcionamento dos sistemas.
31
3.3 MONITORAMENTO
Esta seção irá analisar como é feito o monitoramento de serviços e de desempenho para
máquinas virtuais e os hosts que as hospedam numa visão global orientada ao serviço e à sua
disponibilidade.
Entre os pontos a serem analisados podemos destacar:
• Envio de alertas (email, SMS ou qualquer outro meio definido pelo usuário) quando al-
gum problema ocorrer e também quando houver solução para o mesmo;
• Monitoramento de hosts e máquinas virtuais;
• Monitoramento de serviços de rede (SMTP (Simple Mail Transport Protocol), POP3 (Post
Office Protocol 3), HTTP, NNTP (Network News Transfer Protocol), ICMP (Internet
Control Message Protocol), SNMP (Simple Network Management Protocol));
• Recursos ou equipamentos de rede (largura de banda, uso de CPU e disco);
• Monitoramento remoto utilizando SSH ou SSL (Secure Socket Layer);
• Permitir distinção dos equipamentos que estão indisponíveis dos que estão “inalcançá-
veis”;
• Checagem em paralelo, ou seja, fazer diferentes monitoramentos ao mesmo tempo;
• Interface web;
• Visualização do atual status da rede, notificações, histórico de problemas e logs.
3.4 ALTA DISPONIBILIDADE
Esta seção irá abordar como as soluções apresentadas trabalham para garantir que seus
serviços estejam on line o maior tempo possível. Este quesito envolve a organização e im-
plementação de clusters de hosts e máquinas virtuais visando aumentar a disponibilidade do
ambiente ou mesmo possibilitar a tolerância a falhas.
32
3.5 SITUAÇÃO ATUAL DO PROJETO
Esse quesito aborda a respeito do estado atual dos projetos. Questões como número de
usuários e os segmentos que cada um dos frameworks se desenvolveu e o nível de maturidade
de cada ferramenta em seus projetos serão tratados.
33
4 SOLUÇÕES
4.1 EUCALYPTUS
4.1.1 INTRODUÇÃO
O Eucalyptus é um framework para sistemas de computação em nuvem que opera a nível
de IaaS. Esse sistema possibilita a usuários e administradores de sistemas de Computação em
Nuvem a manipulação de máquinas virtuais através de funcionalidades como criação, controle
e finalização de máquinas virtuais.
O Eucalyptus foi desenvolvido com o intuito de ampliar os estudos acadêmicos em siste-
mas de Computação em Nuvem, visto que, é um dos primeiros sistemas dessa modalidade que
possui código aberto e estrutura adaptada a um escopo de recursos que usa infraestrutura física
(processamento, armazenamento, rede, dentre outras) normalmente encontrada e disponível em
grupos acadêmicos de pesquisa.
De acordo com (EUCALYPTUS, 2012a), o Eucalyptus possui uma arquitetura de software
baseada em Linux que implementa nuvens privadas e híbridas de forma escalável com aumento
da eficiência na infraestrutura existente de TI de uma empresa. Como o Eucalyptus fornece
IaaS, pode-se configurar os recursos (hardware, armazenamento e rede) conforme necessário.
A nuvem do Eucalyptus é implantada no data center das empresas. Como resultado, a orga-
nização tem um controle total da sua infraestrutura de nuvem. É possível implementar e impor
vários níveis de segurança. Dados confidenciais gerenciados pela nuvem não precisam deixar
os limites da empresa, mantendo os dados completamente protegidos contra acesso externo pelo
firewall local.
Eucalyptus foi projetado desde o início para ser fácil de instalar e não intrusivo. Seu fra-
mework é modular independente da linguagem de comunicação. Eucalyptus também é o único
que oferece uma cobertura de rede virtual que isola o tráfego de rede de usuários diferentes,
bem como permite que dois ou mais clusters pertençam a mesma LAN (Local Area Network).
34
4.1.2 HISTÓRIA
De acordo com (EUCALYPTUS, 2012c) o Projeto Eucalyptus começou na Computer Science
Department at the University of California, Santa Barbara com o pesquisador Rich Wolski e
seu time, com o propósito de investigar a área de HPC (High Performance Computing), mais
especificamente a partir do projeto VGrADS (Virtual Grid Application Development Software
Project) financiado pela NSF (National Science Foundation). Para concluir os testes finais
do VGrADS em supercomputadores, foi escolhida a nuvem pública da Amazon. No entanto,
VGrADS sempre foi um projeto conjunto entre Universidade e Laboratórios de Pesquisa com
dados privados e era necessária uma investigação local mais detalhada sobre os comportamentos
de diferentes aplicações.
A partir de então, no início de fevereiro de 2008, iniciou-se o desenvolvimento da plata-
forma opensource Eucalyptus. A primeira versão foi lançada em 29 de maio de 2008 com
suporte apenas a EC2 (Elastic Compute Cloud) e em dezembro de 2008 foi incluída a interface
com o serviço S3 (Simple Storage Service). Em 2009, a equipe Eucalyptus criou a companhia
Eucalyptus Systems Inc. para comercializar o Eucalyptus Enterprise.
4.1.3 ARQUITETURA
Eucalyptus é composto por seis componentes: CLC (Cloud Controller), Walrus, CC (Clus-
ter Controller), SC (Storage Controller), NC (Node Controller), and VMware Broker, este op-
cional. Cada componente é um serviço da web independente. Essa arquitetura permite que
Eucalyptus exponha cada serviço da web como uma API bem definida, independente de idioma
e para oferecer suporte a padrões de serviço Web existentes para comunicação segura entre seus
componentes (EUCALYPTUS, 2012a).
O CLC é o ponto de entrada na nuvem para administradores, desenvolvedores, gerentes de
projeto e usuários finais. O CLC consulta o controlador de nó para obter informações sobre
recursos, toma decisões de programação de alto nível e faz solicitações para os controladores
de cluster. Como interface para a plataforma de gerenciamento, o CLC é responsável por expor
e gerenciar os recursos virtualizados subjacentes (servidores, rede e armazenamento). O CLC
pode ser acessado através do EC2 e um painel de controle baseado na web.
Walrus permite aos usuários armazenar dados persistentes, organizados como buckets e
objetos. Você pode usar o Walrus para criar, excluir e listar os buckets, ou para colocar, receber
e excluir objetos ou para definir políticas de controle de acesso. Walrus tem interface compatível
com o S3. Ele fornece um mecanismo para armazenar e acessar imagens de máquinas virtuais e
35
dados do usuário. Walrus pode ser acessada por usuários finais, se o usuário estiver executando
um cliente de fora da nuvem ou de uma instância de máquina virtual em execução dentro da
nuvem.
O CC geralmente é executado em uma máquina que tem conectividade de rede para ambas
as máquinas que executam o NC e para a máquina executando o CLC. CC’s reunem informações
sobre um conjunto de máquinas e programa a execução da VM em nós específicos. O CC
também gerencia as redes da máquina virtual. Todos os nós associados com um único CC
devem estar na mesma sub-rede.
O SC fornece funcionalidade semelhante para o EBS (Elastic Block Store) da Amazon.
O SC é capaz de fazer a interface com vários sistemas de armazenamento (NFS (Network
File System), dispositivos de SAN (Storage Area Network), iSCSI (Internet Small Computer
System Interface), etc.). EBS exporta volumes de armazenamento que podem ser anexados
por uma VM e montados ou acessados como um dispositivo de bloco cru. Os volumes do
EBS são comumente usados para armazenar dados persistentes. Um volume de EBS não pode
ser compartilhado entre VMs e só pode ser acessado da mesma zona de disponibilidade em
que a máquina virtual está executando. Os usuários podem criar snapshots dos volumes do
EBS que de forma instantânea são armazenados na Walrus e disponibilizados em zonas da
disponibilidade. O suporte a SAN do Eucalyptus permite que você use os dispositivos da SAN
de nível empresarial para hospedar armazenamento EBS dentro de uma nuvem do Eucalyptus.
O NC é executado em qualquer máquina que hospeda instâncias de VM’s. O NC controla
as atividades da VM, incluindo a execução, inspeção e terminação de instâncias. Ele também
obtém e mantém um cache local de imagens de instância e consulta e controla o software de
sistema (sistema operacional do host e o hypervisor) em resposta a consultas e solicitações de
controle de CC. O NC é também responsável pela gestão de ponto de extremidade da rede
virtual.
VMware Broker (Broker) é um componente opcional do Eucalyptus ativado apenas em
versões do Eucalyptus com suporte da VMware. O agente permite que o Eucalyptus implante
máquinas virtuais sobre elementos da infraestrutura do VMware. É por intermédio do Broker
que todas as interações entre o CC e os hypervisors da VMware (ESX/ESXi) ocorrem, direta-
mente ou por meio do VMware vCenter.
A Figura 3 representa a arquitetura do Eucalyptus implementada com alta disponibilidade
do IaaS. Esse tópico será tratado na seção 4.1.7.
36
Figura 3: Arquitetura Eucalyptus (EUCALYPTUS, 2012b)
4.1.4 SISTEMAS DE VIRTUALIZAÇÃO SUPORTADOS
Atualmente o Eucalyptus possui suporte para os seguintes Hypervisors: Xen, KVM e
VMware.
4.1.5 BACKUP
Para fazer backup e restaurar o Eucalyptus deve-se completar as seguintes tarefas:
1. Shut Down no Eucalyptus
2. Backup no Eucalyptus
3. Restauração do Eucalyptus através de um Backup
Shut Down
Devido a uma falha física, mudança de topologia, backup ou upgrade pode ser necessário
realizar um shut down no Eucalyptus. É recomendável que os componentes do Eucalyptus
37
sejam desligados na ordem reversa da qual foram iniciados. Para parar o sistema, deve-se
desligar os componentes na ordem listada abaixo.
Antes de desligar o Eucalyptus é recomendável que todos os usuários sejam notificados que
todas as instâncias serão encerradas:
1. Shut Down All Instances
2. Shut Down the NCs
3. Shut Down the CC
4. Shut Down the Broker
5. Shut Down the SCs
6. Shut Down Walrus
7. Shut Down the CLC
Backup
O backup do Eucalyptus envolve salvar o conteúdo de diretórios específicos de cada com-
ponente. No host do CLC, estes diretórios são:
• O arquivo de configuração
• Os arquivos de bancos de dados
• As chaves de criptografia
Para o host do Walrus (que, a depender da configuração, pode ser o mesmo host do CLC):
• Os buckets do Walrus. O recomendado é fazer o backup desta pasta apenas se tiver bas-
tante espaço disponível no disco de reposição. Se o local dos buckets do Walrus é um
local de armazenamento externo (como NFS), é recomendável o backup local.
Para o host do Storage Controller (pode ser o mesmo host do CLC):
• Os volumes do SC. O recomendado é fazer o backup desta pasta caso não esteja usando
o suporte da SAN. Caso esteja usando um dispositivo SAN com suporte, faça o backup
de volumes armazenado na SAN.
38
Para fazer backup do Eucalyptus:
1. Calcular o espaço em disco necessário para armazenar os arquivos que estarão no backup
(isto é mais relevante para buckets e volumes, que podem ser grandes). Por exemplo, em
uma instalação de um cluster com caminhos de buckets e volumes padrão.
2. Crie um diretório para armazenar o backup em um local com espaço em disco suficiente.
Restauração do Eucalyptus através de um Backup
No caso do sistema sofrer uma falha, pode-se restaurar o Eucalyptus através de um backup,
executando as seguintes tarefas:
1. Desligar quaisquer componentes de Eucalyptus em execução.
2. Caso seja uma recuperação de uma atualização que falhou, e esteja tentanto reverter ou a
atualizar novamente, este seria o momento certo para:
• Remover todos os componentes de software relacionados ao Eucalyptus.
• Instalar a versão apropriada.
• Substituir o estado salvo.
Como possui interação total com o AWS, o Eucalyptus fornece backup através do S3 da
Amazon. O S3 permite o armazenamento e recuperação de qualquer quantidade de dados a
qualquer momento, de qualquer local da Web. O Amazon S3 proporciona o acesso a uma infra-
estrutura de armazenamento de dados altamente dimensionável, confiável, rápida e econômica.
Esta infraestrutura de armazenamento permite o benefício do conhecimento e das economias da
dimensão que a Amazon criou ao suportar a sua própria infraestrutura de missão crítica.
4.1.6 MONITORAMENTO
O Eucalyptus depende de um adequado apoio operacional, além de manutenção. Nesse
sentido, o Eucalyptus fornece acesso à visão atual do estado do serviço e a capacidade de
manipular este estado. Pode-se inspecionar o estado do serviço, garantir a saúde do sistema e
ainda identificar os serviços defeituosos. Você pode modificar um estado de serviço para manter
as atividades e aplicar políticas externas de serviços de colocação.
39
Estado Operacional Em uso pelo sistema DescriçãoENABLED Sim Sim O serviço está funcionando cor-
retamente e está selecionadopara o processamento de pedidos
DISABLED Sim Não O serviço está funcionando cor-retamente, mas não é selecio-nado para o processamento depedidos
NOTREADY Não Não O serviço não está funcionandocorretamente
BROKEN Não Não O serviço não consegue contac-tar o sistema
STOPPED N/A Não O serviço foi parado por um ad-ministrador
Tabela 1: Descrição dos estados do serviço (EUCALYPTUS, 2012a)
Na tabela 1 há a descrição de todos os estados do serviço:
A visualização do estado do serviço indica:
• Tipo de componente do serviço;
• Partição em que o serviço está registrado;
• O nome exclusivo do serviço;
• Visão atual do estado do serviço.
A saída padrão inclui os serviços que são registrados durante a configuração, bem como
informações sobre o serviço de DNS, se houver.
Pode-se fazer pedidos para recuperar informações sobre o serviço que é filtrado por meio
de:
• O estado atual (por exemplo, NOTREADY);
• Host onde o serviço está registrado;
• Partição onde o serviço está registrado;
• Tipo de serviço (por exemplo, CC, ou Walrus).
Na investigação de falhas de serviço, pode-se especificar eventos para retornar um resumo
da última falha. Dessa forma recupera-se informações úteis principalmente para depuração.
40
Nesse sentido, o Eucalyptus é capaz de gerar arquivos de configuração para aplicativos
especializados em monitoramento como o Nagios e o Ganglia.
4.1.7 ALTA DISPONIBILIDADE
Alta disponibilidade (HA) (High Availability) é o resultado da combinação das funcionali-
dades fornecidas pelo Eucalyptus para manter o funcionamento adequado dos sistemas consti-
tuintes. As seguintes funcionalidades estão habilitadas para a manutenção dessa característica:
• Detecção de falhas de serviço e o monitoramento da integridade do sistema: reunir o
status do serviço, determinar a topologia de serviço atual, admitir solicitações que podem
ser atendidas usando somente topologias com serviços com bom funcionamento;
• Ferramentas para interrogar a saúde do sistema: acesso a informações de estado do ser-
viço;
• Pesquisa de erros para ajudar a determinar a causa: o acesso às informações de falha
impacta a função de serviço;
• Failover automatizado quando serviços redundantes são configurados: remoção de servi-
ços com defeito e a habilitação de serviços com bom funcionamento;
• Controle de estado do serviço: capacidade de remover individualmente um componente
de determinado serviço de operação sem interromper o serviço;
• Substituição/restauração de serviços de componentes: processos de substituição/restau-
ração de um componente de serviço após uma falha de perda total, por exemplo falha de
disco.
Noções básicas sobre a disponibilidade do sistema:
O impacto de uma falha do serviço com a disponibilidade do sistema depende da implanta-
ção e configuração do sistema. A tabela 2 detalha o escopo que uma falha de serviço pode ter
em relação a disponibilidade do sistema para cada tipo de componente.
Uma maneira rápida de avaliar a disponibilidade do sistema é determinar se:
• A nuvem tem um CLC habilitado;
• A nuvem tem um Walrus habilitado;
41
Componente Escopo (Região da Falha) DescriçãoCloud Controller Nuvem O CLC é um serviço de nuvem e deve ter ao
menos um seviço ativoWalrus Nuvem Walrus é um serviço de nuvem e deve ter ao
menos um seviço ativoCluster Controller Zona de Disponibilidade CCs estão associados a uma partição e solici-
tações específicas para uma zona de disponi-bilidade de serviço. Uma zona de disponibi-lidade não deve ter um CC operacional, poissolicitações serão rejeitadas para a zona cor-respondente
Storage Controller Zona de Disponibilidade SC estão associados a uma partição e solicita-ções específicas para uma zona de disponibili-dade de serviço. Uma zona de disponibilidadenão deve ter um volume de storage contolleroperacional e solicitações de criação de serãorejeitadas para a zona correspondente
VMware Broker Zona de Disponibilidade VMware Broker está associado a uma parti-ção e solicitações específicas para uma zonade disponibilidade de serviço. Uma zona dedisponibilidade não deve ter um VMware Bro-ker operacional e solicitações serão rejeitadaspara a zona correspondente
Arbitrators Host de Serviços voltados para ousuário
Arbitrators estão associados com um hostque executa serviços de componentes volta-dos para o usuário (CLC, Walrus). Cada hostdeve ter um Arbitrator operacional. Se umhost de serviço do componente tiver um Arbi-trator configurado, mas com defeito uma con-dição de fail-stop ocorre e relatório de servi-ços do hospedeiro gera um erro NOTREADY
Node Controller Compute Host NCs estão associados a cada nó e interagemcom o hypervisor para atender as solicitaçõesespecíficas do nó
Tabela 2: Relação Falha X Disponibilidade do sistema (EUCALYPTUS, 2012a)
• A zona de disponibilidade tem um CC habilitado;
• A zona de disponibilidade tem um SC habilitado;
• O Arbitrator é associado a um host que executa serviços voltados para o usuário (se um
Arbitrator for configurado).
4.1.8 SITUAÇÃO ATUAL DO PROJETO
O Eucalyptus, atualmente, divide-se em dois grandes segmentos: Eucalyptus IaaS e o Eu-
calyptus Opensource. O Eucalyptus Opensource é de código aberto, porém possui algumas
42
limitações se comparado ao Eucalyptus IaaS que é uma solução mais completa possuindo prin-
cipalmente um suporte melhor ao sistema virtual Vmware, além de compatibilidade com o
AWS. Em números, estima-se que atualmente 25.000 nuvens computacionais utilizem uma das
versões do Eucalyptus (ambientes acadêmicos e comerciais).
4.2 OPENNEBULA
4.2.1 INTRODUÇÃO
De acordo com o (OPENNEBULA, 2012a), o OpenNebula.org é um projeto open source
que desenvolve a solução padrão da indústria para criação e gerenciamento de data centers
corporativos virtualizados e infraestruturas na nuvem.
OpenNebula visa proporcionar uma camada de gerenciamento aberta, flexível, extensível
e abrangente para automatizar e orquestrar a operação de datacenters virtualizados, aprovei-
tando e integrando soluções implantadas existentes para redes, armazenamento, virtualização,
monitoramento ou gerenciamento de usuários.
O projeto OpenNebula.org tem os seguintes objetivos a fim de levar a inovação na gestão
de data centers de nuvem corporativa:
• Desenvolver a solução mais avançada, altamente escalável e flexível para a criação e
gerenciamento de data centers virtualizados e infraestruturas na nuvem;
• Garantir a estabilidade e a qualidade de distribuição de software;
• Colaborar com os usuários mais exigentes das ferramentas de gerenciamento de data
centers e nuvem;
• Propagação do conhecimento do projeto;
• Suporte do ecossistema de componentes de código aberto que estão sendo criados em
torno do projeto;
• Apoiar a comunidade de usuários e desenvolvedores que contribuem para o projeto;
• Colaborar com outros projetos de código aberto e comunidades;
• Colaborar com os principais projetos de pesquisa em inovação de Computação em Nu-
vem.
43
Os principais valores do projeto OpenNebula.org são:
• Abertura dos processos e a tecnologia;
• Excelência, por ser um projeto de alta qualidade em cada aspecto de suas operações;
• Cooperação com os esforços de código aberto e projetos de pesquisa para avançar em
Computação em Nuvem;
• Inovação em novas tecnologias e métodos para atender às necessidades de implantações
em larga escala de nuvem.
4.2.2 HISTÓRIA
OpenNebula foi criado como um projeto de pesquisa em 2005 por Ignacio M. Llorente e
Rubén S. Montero. Desde sua primeira versão pública do software em março de 2008, houve-
ram evoluções através de versões de código aberto e agora opera como um projeto open source.
OpenNebula é o resultado de muitos anos de pesquisa e desenvolvimento em gestão eficiente
e escalável de VM’s em intraestruturas distribuídas, com estrita colaboração da comunidade de
usuários (OPENNEBULA, 2012a).
A tecnologia OpenNebula amadureceu graças a esses usuários e desenvolvedores. Dife-
rentes projetos, grupos de pesquisa e empresas construíram novos componentes da nuvem para
complementar e melhorar a funcionalidade fornecida por este conjunto de ferramentas de có-
digo aberto.
Em março de 2010, os principais autores de OpenNebula criaram C12G Labs para per-
mitir que o projeto OpenNebula não seja vinculado exclusivamente ao financiamento público.
OpenNebula.org é agora um projeto gerido pelos C12G Labs.
A tabela 3 fornece um resumo bastante detalhado das principais etapas do projeto OpenNe-
bula.
4.2.3 ARQUITETURA
Visando criar um sistema modular e independente de plataforma, e ao mesmo tempo ten-
tando suprir essas funcionalidades descritas acima, que são raramente encontradas em sistemas
de computação em nuvem similares, foi definida e desenvolvida a arquitetura do OpenNebula,
sendo essa mostrada na Figura 4.
44
Versão LançamentoOpenNebula 3.4 Released 10/04/2012OpenNebula 3.4 Beta Release 29/03/2012OpenNebula 3.2 Released 17/01/2012OpenNebula 3.2 Beta Release 16/12/2011OpenNebula 3.0 Released 03/10/2011OpenNebula 3.0 Beta 2 Release 08/09/2011OpenNebula 3.0 Beta1 Release 20/07/2011OpenNebula 2.2 Released 28/03/2011OpenNebula 2.2 Beta1 Release 02/03/2011OpenNebula 2.0 Released 24/10/2010OpenNebula 2.0 Beta1 Release 28/07/2010OpenNebula Cloud Toolkit Goes Commercial 05/05/2010New Web Site for OpenNebula.org 24/02/2010OpenNebula 1.4 Released 16/12/2009OpenNebula Cloud Announcement 18/11/2009OpenNebula 1.4 RC Released! 18/11/2009OpenNebula 1.4 Beta 2 Released! 30/10/2009New Research Grants to Fund OpenNebula until 2012 04/09/2009OpenNebula Tarantula Stable version 1.2.1 29/07/2009OpenNebula 1.4 Beta1 Codename Hourglass out for Testing 23/07/2009Ubuntu 9.04 (Jaunty Jackalope) has been released today bringing OpenNebula 23/04/2009OpenNebula Wins the Best Demo Award at OGF25/4th EGEE-UF 09/03/2009OpenNebula 1.2 release 06/02/2009OpenNebula 1.2 beta release 05/12/2008Release of OpenNebula 1.0 for Data Center Virtualization & Cloud Solutions 24/07/2008New Technology Preview (TP2) of the OpenNebula (ONE) Virtual Infrastructure Engine 24/07/2008Technology Preview of the OpenNebula (ONE) Virtual Infrastructure Engine 24/07/2008
Tabela 3: Evolução Projeto OpenNebula (OPENNEBULA, 2012a)
Os componentes básicos do OpenNebula são:
• Front End: executa os serviços do OpenNebula;
• Host: habilitados com hypervisor e fornecem os recursos necessários para as VM’s;
• Datastore: armazena as imagens das VMs;
• Service Network e VM Networks: redes físicas usadas para oferecer suporte a serviços
básicos (interligação dos servidores de armazenamento e operações de controle do Open-
Nebula) e a VLAN (Virtual Local Area Network) para as VM’s, respectivamente.
4.2.3.1 FRONT END
O modo de operação da nuvem construída por meio da ferramenta OpenNebula é baseado
em uma arquitetura semelhante ao modelo clássico dos clusters, onde um nó de front end é
45
Figura 4: Sistema Modular OpenNebula (OPENNEBULA, 2012b)
responsável pela execução dos serviços de administração da infraestrutura, enquanto os demais
nós computacionais executam as máquinas virtuais que consumirão os recursos disponíveis.
Neste modelo, ao menos uma rede de comunicação física é utilizada para a interligação de
todos os nós. A Figura 5 ilustra o ambiente constituído pela nuvem privada em questão.
Figura 5: Arquitetura OpenNebula (OPENNEBULA, 2012b)
O nó de front end executa o OpenNebula Daemon, que representa o núcleo do sistema e
administra o ciclo de vida das máquinas virtuais, além de outros aspectos relativos ao funci-
onamento dos demais nós (como rede, armazenamento e hypervisors). Neste nó também são
executados os drivers da ferramenta, responsáveis pela constituição de interfaces entre o núcleo
do sistema e elementos externos, como hypervisors e sistemas de arquivos específicos. O nó de
46
front end pode, ainda, atuar como repositório de imagens de máquinas virtuais, embora este não
seja seu modo de funcionamento ideal.
Os demais nós têm hypervisors habilitados para a execução de máquinas virtuais. A co-
municação entre o nó de front end e os nós com hypervisors se dá por meio de canais de SSH.
Alternativamente, a criptografia destes canais pode ser desabilitada, resultando em um melhor
tempo de transmissão das imagens das máquinas virtuais a serem executadas em um dado nó.
OpenNebula compreende a execução de três tipos de processos, como pode ser visto na
Figura 6.
• O OpenNebula daemon (oned): Um processo centralizado que gerencia o ciclo de vida
das VM’s e orquestra a operação de todos os módulos;
• Os drivers: Para acessar aos sistemas específicos do cluster (por exemplo, armazena-
mento ou hypervisors). Fornecem uma abstração da camada de virtualização subjacente.
Assim, OpenNebula não está vinculado a nenhum ambiente específico, proporcionando
uma camada uniforme de gestão, independiente da tecnologia de virtualização utilizada;
• O scheduler: Para ajustar a locação das VM’s com base em um conjunto de políticas
pré-definidas.
Figura 6: Processos OpenNebula (OPENNEBULA, 2012b)
4.2.3.2 HOST
Os hosts são as máquinas físicas que executarão as VM’s. Durante a instalação, deve-se
configurar a conta administrativa do OpenNebula para ser capaz de utilizar o SSH para os hosts,
e dependendo do hypervisor utilizado essa conta de está autorizada a executar comandos com
privilégios de root.
4.2.3.3 DATASTORE
O OpenNebula usa datastores para lidar com as imagens de disco das VM’s. Imagens
das VM’s são registradas ou criadas (volumes vazios) em um armazenamento de dados. Em
47
geral, cada armazenamento de dados deve ser acessível através do front end usando qualquer
tecnologia adequada NAS (Network-Attached Storage), SAN ou armazenamento com conexão
direta. Quando uma VM é implantada as imagens são transferidas do datastore aos hosts.
4.2.3.4 SERVICE NETWORK E VM NETWORKS
O OpenNebula fornece um subsistema de rede personalizável e facilmente adaptável para
integrar melhor com os requisitos de rede específicos de datacenters existentes.
Para oferecer conectividade de rede para as VM’s entre hosts diferentes, é feita uma conexão
entre a interface de rede de máquina virtual a uma bridge no host físico. Deve-se criar a bridge
com o mesmo nome em todos os hosts.
4.2.4 SISTEMAS DE VIRTUALIZAÇÃO SUPORTADOS
O OpenNebula possui suporte aos seguintes VMM’s: Xen, KVM e VMware.
4.2.5 BACKUP
Para gerenciar o backup, o OpenNebula utiliza o LVM (Logical Volume Manager). Uma
das vantagens deste conceito é que há um único lugar para backup e restauração, no servidor de
armazenamento, onde pode-se usar os recursos de clonagem/snapshot para criar backups dos
servidores sem interrupção do serviço (OPENNEBULA, 2012b). Além disso o LVM permite o
redimensionamento dinâmico, ou seja, com o sistema operacional sendo utilizado.
A grande desvantagem do LVM é que por ser um único disco virtual a recuperação de dados
é bastante prejudicada.
4.2.6 MONITORAMENTO
O OpenNebula oferece interfaces de gerenciamento para integrar as funcionalidades do
núcleo dentro de outras ferramentas de gerenciamento do datacenter, como frameworks para
monitoramento. Para este fim, OpenNebula implementa a libvirt, uma interface aberta para
o gerenciamento de máquinas virtuais, e também uma interface de linha de comando. Estas
funcionalidades são expostas aos usuários externos através de uma interface para nuvem.
A implementação do libvirt no OpenNebula permite usar qualquer aplicativo libvirt em um
nível distribuído. Desta forma é possível usar qualquer ferramenta libvirt, como o virt-manager,
48
para conectar-se ao OpenNebula. Sendo assim você pode gerenciar e monitorar suas VM’s em
um ambiente distribuído usando as ferramentas libvirt.
A arquitetura do libvirt é apresentada na Figura 7 abaixo:
Figura 7: Arquitetura libvirt (OPENNEBULA, 2012c)
Por exemplo, pode-se criar o domínio com virsh create e em seguida o OpenNebula vai
olhar para um recurso adequado, transferir as VM’s e iniciar a VM usando qualquer um dos
hypervisors suportados. A gestão distribuída é completamente transparente para a aplicação
libvirt.
4.2.7 ALTA DISPONIBILIDADE
Tornando o OpenNebula totalmente redundante:
De acordo com (OPENNEBULA, 2012d), para tornar o OpenNebula totalmente redundante
é preciso ter dois controladores de nuvem em modo ativo/passivo de alta disponibilidade. Es-
ses nós também irão fornecer armazenamento exportando uma partição DRBD (Distributed
Replicated Block Device). Os discos da VM serão criados sobre os volumes lógicos LVM
nesta partição. Esta solução, além de ser totalmente redundante, irá fornecer armazenamento
de alta velocidade porque não usamos arquivos NFS para implantar as partições da VM e sim
49
snapshots. No entanto, o NFS ainda se faz necessário para exportar o diretório de dados da
nuvem do OpenNebula.
Estas são as ações a serem tomadas:
• Instalação de 2 servidores, habilitando o SSH em ambos;
• Criar um diretório específico para replicação do DRBD e um outro para exportação dos
sistemas de arquivos da VM;
• Configurar 2 placas de rede para gerenciar a replicação de dados e se comunicar com a
SAN e uma 3a placa para acesso externo do cluster a LAN;
• Configurar a LAN;
• Configurar o MySQL;
• Configurar o DRBD.
A partir daí, como já mencionado, as duas partições DRBD serão visíveis através da rede,
embora de formas diferentes: um disco será exportado através de NFS, enquanto o outro apre-
sentará suas partições LVM para o hypervisor.
4.2.8 SITUAÇÃO ATUAL DO PROJETO
O OpenNebula mantem apenas um projeto que possui código aberto. Atualmente, esse
framework é largamente utilizado principalmente por universidades, centros de pesquisa e em-
presas de ramos como hospedagem de dados e telefonia. Estima-se que o OpenNebula distribua
4.000 cópias do seu projeto por mês.
4.3 OPENQRM
4.3.1 INTRODUÇÃO
O openQRM é uma solução em código aberto para gerenciamento de data centers em uma
nuvem computacional. Projetado para automatizar os data centers e gerenciá-los de uma ma-
neira escalável, o openQRM possui entre suas muitas características uma arquitetura exclusiva
que unifica a implantação entre máquinas físicas e virtuais dentro de um único console de geren-
ciamento. openQRM integra-se com todas as principais tecnologias de virtualização e suporta
50
de forma transparente migrações P2V (Physical-to-Virtual), V2P (Virtual-to-Physical) e V2V
(Virtual-to-Virtual).
O storage do openQRM utiliza snapshots para clonar servidores para implantação rápida,
backup / restauração, servidor para controle de versão, redimensionamento de disco e armaze-
namento persistente em nuvem. O openQRM também fornece failover “N para 1” permitindo
que grupos de servidores possam usar um único servidor em standby. O failover de máquinas
físicas para virtuais também é realizado.
Com seu conceito de “capacidade de plug” o openQRM combina produtos de código aberto
e comerciais de terceiros na administração de data centers, monitoramento de sistema e serviço,
alta disponibilidade e com provisionamento automatizado dentro de um único console de ge-
renciamento.
4.3.2 HISTÓRIA
A versão inicial do openQRM foi desenvolvida pela empresa Qlusters fundada em 2001.
Inicialmente a Qlusters esteve concentrada em HPC mudando seu foco de negócios para o
gerenciamento de data centers em 2003. A primeira versão do openQRM foi baseada na lin-
guagem de programação Java sendo desenvolvida até a versão 3.1.4 quando a empresa fechou
suas portas no início de 2008. O impressionante é que a versão do openQRM de 2005 já incluia
um sistema de provisionamento totalmente automatizado e o suporte para implantação de má-
quinas virtuais muito semelhante ao conceito que hoje é atribuído a Computação em Nuvem,
sendo nomeado “Utility Computing”.
Com um crescimento grande e complexo causado por um longo desenvolvimento histórico
das últimas versões do 3.x, o openQRM teve sua licença comercial alterada para open source em
2006. Matthias Rechenburg estava trabalhando como gerente de projetos da Qlusters desde o
início desta versão do openQRM. Com o fechamento da Qlusters em 2008 ele decidiu continuar
com o projeto do openQRM dirigido a comunidade open source.
A versão 4.0 do openQRM foi reescrita do zero, tendo suas características e mecanismos
voltados para a linguagem PHP (Hypertext Preprocessor) tornando-se muito mais leve. No
prazo de apenas 2 anos de re-design a equipe do openQRM conseguiu superar as funcionali-
dades do openQRM “antigo”, além de deixar pronta a versão corporativa. O lançamento do
openQRM 5.0 está previsto para 1o de agosto de 2012.
Mesmo após o fechamento da Qlusters a equipe do openQRM decidiu manter seu nome
original, hoje administrada pela openQRM Enterprise.
51
A tabela 4 fornece um resumo bastante detalhado das principais etapas do projeto openQRM.
Versão Data de LançamentoopenQRM-4.9 31/10/2011openQRM-4.8 31/03/2001openQRM-4.7 30/09/2010openQRM-4.6 05/01/2010openQRM 4.5 18/07/2009openQRM 4.4 14/03/2009openQRM 4.3 30/12/2008openQRM 4.2 15/11/2008openQRM 3.1.4 26/09/2008openQRM 4.1 26/09/2008openQRM 4.0 13/06/2008openQRM 3.5.2 (discontinued) 08/04/2008openQRM 3.1.3 18/03/2007openQRM 3.1.2 28/12/2006openQRM 3.1 22/11/2006openQRM 3.0 05/10/2006openQRM 2.2 25/07/2006openQRM 2.1 08/02/2006
Tabela 4: Evolução Projeto openQRM (SOURCEFORGE, 2012)
4.3.3 ARQUITETURA
Como a visão geral do conceito apontada para o gerenciamento de um data center com to-
dos os seus componentes é uma tarefa difícil que faz com que (como conhecemos) rapidamente
sobrecarregue os recursos de um único aplicativo, a alta disponibilidade só pode funcionar bem
se todos os componentes estão bem integrados e colaborem de uma forma definida.
O servidor do openQRM é constituído pela “base” e pelos “plugins”. A base centralizada
“apenas” gerencia os plugins e fornece a estrutura para que estes possam interagir por exemplo,
com recursos, imagem, storage e outros objetos.
Essa abordagem tem diversas vantagens:
• desenvolvimento rápido porque os desenvolvedores podem trabalhar em paralelo com
plugins diferentes;
• robustez reforçada por causa de uma base robusta que não muda muito;
• fácil integração de componentes de terceiros através de uma API de plugin bem definida;
• os bugs em um dos plugins não prejudicam o sistema base;
52
Figura 8: Arquitetura openQRM (OPENQRM, 2012b)
• menor complexidade porque o plugin gerencia apenas o seu próprio ambiente;
• menos código no mecanismo base e menos código significa menos bugs;
• melhor escalabilidade porque os plugins podem ser ativados / desativados em tempo real;
• os plugins são fáceis de se desenvolver por causa do conceito base com que foram dese-
nhados.
4.3.4 SISTEMAS DE VIRTUALIZAÇÃO SUPORTADOS
O openQRM possui suporte ao Xen, KVM e VMware. Também possui suporte ao Linux-
VServer.
4.3.5 BACKUP
Assim como o OpenNebula, o openQRM também utiliza o LVM.
4.3.6 MONITORAMENTO
Em relação ao monitoramento, nenhuma ferramenta é apresentada para o controle dos com-
ponentes do openQRM e das máquinas virtuais. O openQRM possui integração com softwares
de monitoramento (tais como Nagios, Zabbix e collectd).
53
4.3.7 ALTA DISPONIBILIDADE
Ao falar sobre “TI Verde” a abordagem atual é usar a virtualização para consolidar muitos
servidores físicos para executar como virtuais em um host hypervisor. Enquanto este método é
bom para diminuir o consumo geral de energia, muitas vezes é esquecido que dada a situação,
no caso do único host hypervisor falhar todos os servidores virtuais que rodam nesse host tam-
bém ficarão indisponíveis. Dessa forma, no moderno mundo virtual, se faz necessário cuidar
especialmente da alta disponibilidade.
HA em nível de recurso:
O método usual para manter o sistema altamente disponível é utilizar 10 servidores perso-
nalizados:
• Obter 10 servidores adicionais com as mesmas configurações do host em uso;
• Configurar a sincronização dos discos entre os 10 pares de servidor;
• Implementar uma solução de fail-over para o serviço em execução sobre os 10 clusters.
Como resultado, este método requer 20 sistemas físicos para manter 10 servidores de alta
disponibilidade.
HA no openQRM:
• Implantar os 10 servidores personalizados via openQRM;
• Adicione 1 servidor como Hot-Standby.
No caso de um dos 10 servidores personalizados parar o openQRM vai usar o sistema de
um disponível para reiniciá-lo através dos seus métodos de implementação rápida. Sendo assim,
10 (ou mais) servidores de alta disponibilidade podem ser configurados com apenas uma única
sendo Hot-Standby. Isso economiza o consumo de energia de 9 servidores!
HA em Nível de Aplicação:
Para o nível de aplicação, HA pode ser feito no openQRM adicionando verificações per-
sonalizadas pelo Nagios para monitorar o estado do serviço de uma aplicação específica. Caso
esta verificação falhe, ele pode tomar algumas ações para reativar o serviço:
• Reiniciar o serviço;
54
• Forçar um reboot;
• Forçar um fail-over para uma aplicação passiva de espera.
HA em nível de aplicação ainda não está automatizado no openQRM, portanto deve ser
realizado de forma manual.
HA para o servidor de openQRM:
A equipe do openQRM recomenda usar o Linux-HA para a configuração da alta disponibi-
lidade.
Segue abaixo os requisitos para o openQRM HA:
• 2 ou mais sistemas para os nós do cluster ativos e utilizando openQRM
• Armazenamento-Compartilhado fornecendo ao servidor openQRM arquivo de dados
• Base de dados (remoto) externo
Pode-se levar em consideração o openQRM instalado no sistema físico ou na máquina
virtual.
Abaixo são descritos os passos para instalar o openQRM em alta disponibilidade:
• Instalar o sistema operacional nos sistemas dedicados para os nós do cluster openQRM
• Montar o armazenamento compartilhado em openQRM em todos os nós do cluster
• Configurar o Linux-HA com um cluster de endereço IP
• Instalar o openQRM em um único sistema!
O Linux-HA ficará responsável por sempre manter o sistema em funcionamento.
4.3.8 SITUAÇÃO ATUAL DO PROJETO
O openQRM divide-se em dois projetos: o Open Source e o Enterprise. O openQRM
Open Source é de código aberto, porém possui algumas limitações se comparado ao openQRM
Enterprise que é uma solução mais completa possuindo principalmente um suporte melhor ao
Vmware, além de autenticação pelo protocolo LDAP (Lightweight Directory Access Protocol)
(OPENQRM, 2012a).
55
4.4 OPENSTACK
4.4.1 INTRODUÇÃO
OpenStack oferece software open source para criar nuvens públicas e privadas. OpenStack
é uma comunidade e um projeto para ajudar as organizações a executar nuvens de computação
virtuais ou storage. OpenStack contém uma coleção de projetos open source que são mantidos
pela comunidade, incluindo o Compute (codinome Nova), o Object Storage (codinome Swift) e
o Image Service (codinome Glance). OpenStack fornece uma plataforma operacional ou toolkit,
para orquestrar as nuvens.
OpenStack é mais facilmente definido quando os conceitos de Computação em Nuvem se
tornam aparentes. Dessa forma o OpenStack tem como missão fornecer nuvens computacionais
públicas e privadas de forma escalável e elástica. No coração de sua missão há um par de
requisitos básicos: nuvens devem ser simples de implementar e massivamente escaláveis.
4.4.2 HISTÓRIA
O OpenStack é um conjunto de projetos de software open source que empresas e provedores
de serviços podem usar para configurar e operar sua infraestrutura de computação e armazena-
mento em nuvem. Fundada em 2010 teve a Rackspace (provedor de infraestrutura americano) e
a NASA (National Aeronautics and Space Administration) (agência espacial americana) como
seus principais contribuidores iniciais para o projeto. A Rackspace forneceu sua plataforma
“Cloud Files” para implementar o aspecto de armazenamento (Object Storage) do OpenStack,
enquanto que a NASA entrou com o “Nebula” para implementar o lado computacional (Com-
pute). O consórcio OpenStack desde então agregou mais de 100 membros em menos de um
ano, incluindo a Canonical (responsável pelo Ubuntu), Dell e Citrix.
“Essex” foi a última versão (das cinco) lançada pelo OpenStack, em abril de 2012. Antes
desta foram lançadas as versões Austin, Bexar e Cactus, além da Diablo.
A tabela 5 mostra a evolução do projeto OpenStack, indicando a data de lançamento prevista
para sua nova versão, a Folsom:
4.4.3 ARQUITETURA
O OpenStack consiste de vários componentes principais. Um “controlador de nuvem” con-
tém muitos desses componentes e interage com todos os outros. Um servidor API atua como
56
Versão Data de LançamentoFolsom 27/09/2012 (previsão)Essex 05/04/2012Diablo 22/09/2011Cactus 15/04/2011Bexar 03/02/2011Austin 21/10/2010
Tabela 5: Evolução Projeto OpenStack (OPENSTACK, 2012b)
web service front end da controladora de nuvem. O controlador fornece recursos de servidor e
contém, normalmente, o serviço de computação.
O componente The Object Store, opcionalmente, oferece serviços de armazenamento. Um
gerenciador de autenticação fornece, além desse serviço, autorização quando usado com o sis-
tema de computação ou você pode usar o “Identity Service” (keystone) como um serviço de
autenticação separado.
Um controlador de volume fornece armazenamento de blocos rápido e permanente para os
servidores. Um controlador de rede proporciona redes virtuais para permitir que servidores pos-
sam interagir uns com os outros e com a rede pública. Um programador seleciona o controlador
mais adequado para uma instância de host.
O OpenStack é construído sobre uma arquitetura baseada em mensagens, nada comparti-
lhado. Um controlador de nuvem se comunica com o armazenamento do objeto interno através
de HTTP, mas ele se comunica com um scheduler, com o controlador de rede e com o contro-
lador de volume via AMQP (Advanced Message Queue Protocol).
Para evitar o bloqueio de cada componente enquanto aguarda uma resposta, o OpenStack
usa chamadas assíncronas, com um retorno de chamada que obtém acionado quando uma res-
posta é recebida.
Para obter a propriedade de “nada compartilhado” com várias cópias do mesmo compo-
nente, o OpenStack mantém todo o estado do sistema de nuvem em um banco de dados.
Object Storage (“Swift”): oferece armazenamento de objeto. Ele permite que armazena-
mento ou recuperação de arquivos, mas não montar diretórios como um servidor de arquivos).
Existem várias empresas de prestação de serviços de armazenamento comercial baseados em
Swift. Estes incluem KT, Rackspace (que originou o Swift) e a Internap.
Image Service (“Glance”): fornece um catálogo e um repositório de imagens de disco
virtual. Estas imagens de disco são principalmente usadas no OpenStack Compute. Embora
este serviço seja tecnicamente opcional, qualquer nuvem necessitará dele.
57
Compute (“Nova”): fornece servidores virtuais a demanda. Semelhante ao serviço de EC2
da Amazon, ele também fornece serviços de volume análogos para EBS. É usado internamente
na NASA (onde se originou).
A partir da quinta versão foram promovidos dois novos projetos para o status do projeto
“núcleo”:
Dashboard (“Horizon”): fornece uma interface de usuário baseada na web modular para
todos os serviços do OpenStack.
Identity (“Keystone”): fornece autenticação e autorização de todos os serviços do OpenS-
tack. Ele também fornece um catálogo de serviços dentro de uma implantação específica.
Esses novos projetos oferecem infraestrutura adicional para oferecer suporte aos três proje-
tos originais.
Figura 9: Arquitetura OpenStack (OPENSTACK, 2012a)
4.4.4 SISTEMAS DE VIRTUALIZAÇÃO SUPORTADOS
O OpenStack possui suporte ao KVM, LXC (Linux Containers), QEMU (Quick EMUlator),
UML (User Mode Linux), VMware e Xen.
4.4.5 BACKUP
Processo de recuperação de desastres através do Nova
58
Um incidente nunca é planejado, por sua definição. Às vezes, simplesmente as coisas não
dão certo.
Nesta seção, será analisado o gerenciamento da nuvem após um desastre e como facilmente
fazer o backup dos volumes de armazenamento persistente, que é uma outra abordagem, quando
enfrentar um desastre.
Apresentação do processo de recuperação de desastres
Um desastre pode acontecer com vários componentes da arquitetura: uma falha no disco,
uma perda de rede, um corte de energia, etc. Neste exemplo, supomos a seguinte configuração:
1. Um controlador de nuvem (Nova-api, Nova-objecstore, Nova-volume, Nova-network)
2. Um nó de computação (Nova-compute)
3. Uma SAN usada pelos volumes de Nova (aka SAN)
O exemplo de desastre será o pior: uma queda de energia. Perda de potência aplica-se a três
componentes. Abaixo temos o que funciona e como são executados antes do acidente:
• De SAN para o controlador de nuvem, nós temos uma sessão iSCSI ativa (usada para o
volume de Nova).
• Do controlador de nuvem para o nó de computadores também temos sessões iSCSI ativas
(gestão do volume de Nova).
• Para cada volume uma sessão iSCSI é feita (portanto, se temos 14 volumes EBS, temos
14 sessões).
• Do controlador de nuvem para o nó de computadores também temos iptables/ebtables que
permite o acesso do controlador de nuvem para a instância em execução.
• E, pelo menos, do controlador de nuvem para o nó de computadores, temo salvo no
banco de dados o estado atual de instâncias “executando” e a fixação de volumes (ponto
de montagem, identificação de volume, o status do volume, etc...)
Agora, após a queda de energia e o reinício de todos os componentes de hardware, a situação
é a seguinte:
• A partir da SAN para a nuvem, a sessão iSCSI já não existe.
59
• A partir do controlador de nuvem para o nó de computação, as sessões iSCSI já não
existem.
• A partir do controlador de nuvem para o nó de computação, o iptables e ebtables são
recriados, desde que, no boot, a rede da Nova reaplique as configurações.
• A partir do controlador de nuvem, instâncias transformam-se em um estado de desliga-
mento (porque já não estão funcionando)
• No banco de dados, dados não foram atualizados corretamente, já que a Nova não poderia
ter “adivinhado” o acidente.
O plano é executar as seguintes tarefas na ordem exata. Qualquer etapa extra seria perigosa
nesta fase:
1. Obter a relação atual de um volume a sua instância, uma vez que o anexo será recriado.
2. Atualizar o banco de dados para limpar o estado parado. (Depois disso, a etapa anterior
não poderá ser realizada).
3. É preciso reiniciar as instâncias (sair de um estado de “desligamento” para um estado de
“execução”).
4. Após a reinicialização, reanexar os volumes de suas respectivas instâncias.
O processo de recuperação de desastres
• Instanciar o volume, recriando o anexo:
Essa relação poderia ser figurada executando a lista de volumes da nova
• Atualização de banco de dados
Em segundo lugar, atualizar o banco de dados para limpar o estado parado. Agora que os
anexos estão salvos se faz necessário restaurar cada volume no banco de dados limpo.
Agora, ao executar a lista de volumes da Nova todos os volumes devem estar disponíveis.
• Reinício de instâncias
É preciso reiniciar as instâncias. Isso pode ser feito por meio de um reinício na Nova.
60
Nesta fase, dependendo da imagem, para alguns casos irão reiniciar completamente e se
tornar alcançáveis, enquanto outros vão parar no estágio “plymouth”.
Não é aconselhável reinicializar uma segunda vez os que estão parados nessa fase (abaixo,
a quarta etapa). Na verdade, isso depende se foi adicionada uma entrada para esse volume
ou não. Imagens criadas podem permanecer em um estado pendente, enquanto outras vão
ignorar o volume ausente e começar. De qualquer modo a ideia dessa fase é somente pedir
a Nova para reiniciar a cada instância, para que o estado armazenado seja preservado.
• Anexar volume
Após a reinicialização, pode-se reanexar os volumes de suas respectivas instâncias. Agora
se a Nova tiver restaurado o estado de direito, é hora de anexar os volumes.
Nessa fase, instâncias que estavam pendentes na seqüência de inicialização (“plymouth”)
irão automaticamente continuar seu reinício normalmente.
• SSH em instâncias
Se alguns serviços dependem do volume o ideal seria simplesmente reiniciar a instância.
Essa reinicialização precisa ser feita desde a instância propriamente dita, não através de
Nova.
Recuperação de desastres com script
Existe um script que executa estes cinco passos. O “test mode” permite que você execute
essa seqüência inteira para apenas uma instância.
Para reproduzir a perda de energia, conecte com o nó de computação que executa essa
mesma instância e feche a sessão iSCSI. Essa ação deve ser feita manualmente e não através de
Nova.
O OpenStack utiliza o XenCenter para fazer o monitoramento e gerenciamento das máqui-
nas virtuais. O XenCenter possui suporte flexível ao console utilizado. Para o gerenciamento
do backup a sugestão é pelo uso do Gladinet Cloud Backup. Este software foi lançado primeiro
como um produto independente. Hoje, o Gladinet Cloud Backup se integra com o serviço de
Shadow Copy do Windows para fornecer serviços de nuvem para armazenamento de snapshots.
4.4.6 MONITORAMENTO
O monitoramento do OpenStack é feito através do Nova, seu gerenciador da infraestrutura
computacional. Através da API Server (nova-api), Nova fornece uma interface para que o
61
mundo exterior interaja com a infraestrutura da nuvem. O API Server é o único componente do
Nova que o mundo exterior usa para gerenciar a infraestrutura. O gerenciamento é feito através
de web services, utilizando uma API compatível com a EC2. O API Server se comunica com
os outros componentes necessários através da Message Queue (“Fila de Mensagens”).
Os componentes do OpenStack comunicam-se entre si através do protocolo AMQP imple-
mentado pela Message Queue. O Nova usa chamadas assíncronas para as requisições, com um
mecanismo que é acionado quando a resposta é recebida. Uma vez que a comunicação é as-
síncrona, nenhuma das pontas fica bloqueada por muito tempo em um estado de espera. Isto é
especialmente importante dado que muitas ações invocadas através das APIs envolvem tempos
longos, como criar uma instância ou fazer o upload de uma imagem.
O OpenStack utiliza o XenCenter para fazer o monitoramento e gerenciamento das máqui-
nas virtuais.
4.4.7 ALTA DISPONIBILIDADE
Opções existentes de alta disponibilidade para redes
O DHCP (Dynamic Host Configuration Protocol) é tratado pela nova-network. Os hosts de
computação podem, opcionalmente, ter seus próprios IPs públicos, ou eles podem usar o host
de rede como sua porta de entrada. Este modo é bastante simples e funciona na maioria das
situações, mas tem uma grande desvantagem: a rede possui um ponto único de falha! Se o host
de rede for desligado por qualquer motivo, é impossível se comunicar com as VMs. Aqui estão
algumas opções para evitar o ponto único de falha.
HA opção 1: conexão
Para eliminar o host de rede como um ponto único de falha, nova-compute pode ser con-
figurado para permitir que cada host de computação faça todos os trabalhos de rede para suas
próprias VMs. Cada host de computação faz NAT (Network Address Translation), DHCP e
atua como um gateway para todas as suas próprias VMs.
Esta instalação requer adicionar um IP na rede VM para cada host no sistema e isso implica
um pouco mais de sobrecarga nos hosts de computação.
Dessa forma todos os hosts do sistema estarão executando o nova-compute, nova-network
e serviços da nova-api. Cada host faz DHCP e faz NAT para o tráfego de público para as VMs
em execução no host específico. Neste modelo, cada host de computação requer uma conexão
à Internet pública e a cada host também é atribuído um endereço de rede VM onde ele escuta o
62
tráfego DHCP. O serviço da nova-api é necessário para que ele possa atuar como um servidor
de metadados para as instâncias.
Para executar no modo HA, cada host de computação deve executar os seguintes serviços:
• nova-compute
• nova-network
• nova-api
HA opção 2: Failover
Nos laboratórios da NTT (Nippon Telegraph and Telephone Corporation) foi criado um
ha-linux que permite um failover de 4 segundos para um backup dinâmico do host de rede.
Esta solução é definitivamente uma opção, embora exija um segundo host que essencial-
mente não faz nada a não ser que haja uma falha. Além disso, 4 segundos podem ser muito
longos para algumas aplicações em tempo real.
HA opção 3: Multi-NIC
A Nova possui suporte para multi-NIC. Dessa forma pode-se fazer uma bridge de uma
determinada VM em várias redes. Sendo assim surgem mais algumas opções de alta disponi-
bilidade. É possível configurar duas redes em VLANs separadas e dar as VMs uma NIC e um
IP em cada rede. Cada uma dessas redes pode ter seu próprio host de rede atuando como o
gateway.
Neste caso, a VM tem dois caminhos possíveis para ser roteada. Se um deles falhar, ele tem
a opção de usar o outro. A desvantagem dessa abordagem é que ele libera o gerenciamento de
cenários de falha para o convidado. O convidado deve estar ciente das várias redes e ter uma
estratégia para alternar entre eles.
4.4.8 SITUAÇÃO ATUAL DO PROJETO
Conhecido como o “’Linux’ da Computação em Nuvem” (STACKOPS, 2012), o OpenStack
mantem 3 serviços principais em seu projeto de código aberto, o de Infraestrutura Computaci-
onal (Nova), o de Infraestrutura de Armazenamento (Swift) e o de Gerenciamento de Imagens
(Glance). Atualmente, esse framework é utilizado por 3386 especialistas, entre pesquisadores e
desenvolvedores, além de 183 empresas.
63
5 COMPARATIVO DAS SOLUÇÕES
5.1 SISTEMAS DE VIRTUALIZAÇÃO SUPORTADOS
Em relação aos sistemas de virtualização é possível destacar que todas as soluções apresen-
tadas suportam o Xen, KVM e o VMware. Já o openQRM, além dos citados, suporta também o
Linux-VServer (fornece virtualização para sistemas GNU/Linux). Entretanto a solução que se
destaca nessa característica é o OpenStack, que suporta os mais variados sistemas de virtuali-
zação, como o LXC (fornece virtualização para sistemas Linux), QEMU (emulador genérico e
open source) e UML (fornece virtualização para sistemas Linux).
Sendo assim, em relação ao critério Sistemas de Virtualização Suportados, o OpenStack é
o que abrange mais Hypervisors entre as soluções apresentadas.
5.2 BACKUP
O XenCenter foi projetado com uma interface gráfica simples, criando snapshots de uma
máquina virtual para fins de backup de forma rápida e segura, já que não interrompe os discos
da máquina virtual quando executado.
O XenCenter permite snapshots manuais ou por scripts, além de possuir disaster recovery
integrado.
Além disso o XenCenter possui integração com o OpenStack, o que facilita a instalação/-
configuração e evita problemas no uso diário.
Sendo assim, em relação ao critério Backup, o OpenStack se destaca das demais soluções.
5.3 MONITORAMENTO
Observando as características das ferramentas de monitoramento utilizadas pelas soluções
observa-se que XenCenter é a ferramenta mais completa entre as apresentadas.
64
Principais características do XenCenter:
• Gestão de instalação, configuração e ciclo de vida da máquina virtual completa
• Acesso aos consoles VM (Xvnc no Linux e Remote Desktop no Windows)
• Configuração de armazenamento remoto, incluindo suporte a iSCSI
• Gerenciamento dinâmico de memória
• Integração com o OpenStack
• Entre outras
Sendo assim, em relação ao critério Monitoramento, o OpenStack se destaca das demais
soluções.
5.4 ALTA DISPONIBILIDADE
A alta disponibilidade apresentada pelo OpenStack chama a atenção por oferecer 3 opções:
por conexão, por failover e por multi-nic. A API Nova é usada nesse processo e o destaque fica
por conta da HA por failover. Essa opção utiliza um ha-linux produzido pela NTT que permite
um failover de 4 segundos para um backup dinâmico de um host.
Sendo assim, em relação ao critério Alta Disponibilidade, o OpenStack se destaca das
demais soluções.
5.5 SITUAÇÃO ATUAL DO PROJETO
Com um acordo com a AWS anunciado em março de 2012, a Eucalyptus firmou parceria de
compatibilidade com a Amazon. Isso significa que o Eucalyptus irá fornecer compatibilidade
com o principais serviços da Amazon (EC2, EBS, AMI, S3 e IAM).
Dessa forma a Eucalyptus terá o monitoramento, gerenciamento de serviços de nuvem e
gerenciamento de imagem totalmente providos pela AWS, além de poder padronizar a aplicação
e condições de uso ajudando a manter dados privados em seu próprio data center.
Sendo assim, em relação ao critério Situação Atual do Projeto, o Eucalyptus se destaca das
demais soluções.
65
5.6 QUADRO COMPARATIVO
Critérios Eucalyptus OpenNebula openQRM OpenStackHypervisors Supor-tados
Xen, KVM eVMware
Xen, KVM eVMware
Xen, KVM,VMware e Linux-VServer
Xen, KVM,VMware, LXC,QEMU e UML
Backup Amazon S3 LVM LVM XenCenterMonitoramento Nagios e Ganglia libvirt Nagios, Zabbix e
collectedXenCenter
Alta Disponibili-dade
Cloud Controller Redundância Linux-HA Nova
Situação Atual doProjeto
2 projetos; 25 milnuvens
1 projeto; 4 mil có-pias/mês
2 projetos; N/A 1 projeto (3 servi-ços); 3386 pesqui-sadores e 183 em-presas
Tabela 6: Quadro Comparativo das Soluções
66
6 CONCLUSÃO
Este trabalho propôs uma análise comparativa das principais soluções de Computação em
Nuvem. Dentre as soluções avaliadas e de acordo com os critérios abordados, podemos destacar
o OpenStack.
Apresentando suporte a hypervisors diversificados, além dos mais tradicionais, o OpenS-
tack, através do XenCenter, garante o backup e o monitoramento de suas nuvens com estabili-
dade, já que a ferramenta é integrada a solução. O OpenStack também dispõe de um processo
de alta disponibilidade bastante eficaz, além de contar com a NASA como contribuidora inicial
do projeto e com outras grandes empresas como usuários atuais (Intel e AT&T).
6.1 TRABALHOS FUTUROS
Algumas possibilidades de trabalhos futuros estão relacionadas a inclusão de outros crité-
rios avaliativos, tais como:
• Gerência e Alocação das Máquinas Virtuais (Provisionamento)
• Gerência e Alocação de Recursos (Armazenamento, CPU, Memória e Rede)
• Realocação Dinâmica de Recursos
• API
67
REFERÊNCIAS
COMPUTERWORLD. 11 categorias de cloud computing - Tecnologia - COM-PUTERWORLD. 2010. Último acesso em 20 de maio de 2012. Disponível em:<http://computerworld.uol.com.br/tecnologia/2010/03/03/11-categorias-de-cloud-computing/>.
EUCALYPTUS. Eucalyptus 3.0.2 Administration Guide. [S.l.], 2012. Disponível em:<http://www.eucalyptus.com/eucalyptus-cloud/documentation>.
EUCALYPTUS. Eucalyptus Architecture | Cloud Computing Software fromEucalyptus. 2012. Último acesso em 17 de junho de 2012. Disponível em:<http://www.eucalyptus.com/eucalyptus-cloud/iaas/architecture>.
EUCALYPTUS. The Eucalyptus Story. 2012. Último acesso em 17 de junho de 2012.Disponível em: <http://www.eucalyptus.com/about/story>.
IBM. Modelos de serviço de computação em nuvem, Parte 1: Infraestruturacomo serviço. 2011. Último acesso em 23 de maio de 2012. Disponível em:<http://www.ibm.com/developerworks/br/cloud/library/cl-cloudservices1iaas/>.
IBM. Modelos de Serviços de Computação em Nuvem, Parte 2: Plataformacomo Serviço. 2011. Último acesso em 23 de maio de 2012. Disponível em:<http://www.ibm.com/developerworks/br/cloud/library/cl-cloudservices2paas/>.
IBM. Modelos de Serviços de Computação em Nuvem, Parte 3: Softwarecomo Serviço. 2011. Último acesso em 23 de maio de 2012. Disponível em:<http://www.ibm.com/developerworks/br/cloud/library/cl-cloudservices3saas/index.html>.
MICROSOFT. Web Services. 2006. Último acesso em 23 de maio de 2012. Disponível em:<http://msdn.microsoft.com/pt-br/library/cc564893.aspx>.
OPENNEBULA. About the OpenNebula.org Project. 2012. Último acesso em 23 de junho de2012. Disponível em: <http://www.opennebula.org/about:about>.
OPENNEBULA. OpenNebula: The Open Source Solution for Data Center Virtualization.2012. Último acesso em 17 de junho de 2012. Disponível em: <http://www.opennebula.org/>.
OPENNEBULA. OpenNebula: The Open Source Solution for Data Center Vir-tualization. 2012. Último acesso em 24 de junho de 2012. Disponível em:<http://opennebula.org/documentation:archives:rel1.4:libvirtapi>.
OPENNEBULA. Setting up High Availability in OpenNebula with LVM. 2012. Último acessoem 21 de junho de 2012. Disponível em: <http://blog.opennebula.org/?p=1523>.
68
OPENQRM. openQRM | Leading Open Source Data Center and Cloud Computing Plattform- Version Comparison. 2012. Último acesso em 26 de junho de 2012. Disponível em:<http://www.openqrm-enterprise.com/about-openqrm/feature-comparison.html>.
OPENQRM. openQRM | openQRM keeps your data center up and running. 2012. Últimoacesso em 24 de junho de 2012. Disponível em: <http://www.openqrm.com/?q=node/42>.
OPENSTACK. OpenStack Compute Starter Guide. [S.l.], 2012. Disponível em:<http://docs.openstack.org/>.
OPENSTACK. Releases - Wiki. 2012. Último acesso em 24 de junho de 2012. Disponível em:<http://wiki.openstack.org/Releases>.
RUSCHEL, H.; ZANOTTO, M. S.; MOTA, W. C. da. Computação em nuvem. p. 15, 2010.
SLB. TI VERDE - TI Verde - Software Livre Brasil. 2009. Último acesso em 25 de maio de2012. Disponível em: <http://softwarelivre.org/ti-verde>.
SOURCEFORGE. openQRM - Browse Files at SourceForge.net. 2012. Último acesso em 19de junho de 2012. Disponível em: <http://sourceforge.net/projects/openqrm/files/>.
STACKOPS. StackOps. 2012. Último acesso em 25 de junho de 2012. Disponível em:<http://www.stackops.com/>.
TANENBAUM, A. S.; STEEN, M. V. Distributed Systems. Principles and Paradigms. 2a. ed.[S.l.: s.n.], 2006. 705 p.
UFRJ. Computação em Nuvem. 2009. Último acesso em 20 de maio de 2012. Disponível em:<http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2009_2/seabra/arquitetura.html>.
VERAS, M. Virtualização - Componente Central do Datacenter. 1a. ed. [S.l.]: Brasport, 2011.364 p.
VERAS, M. Cloud Computing - Nova Arquitetura da TI. 1a. ed. [S.l.: s.n.], 2012. 240 p.
WEB, I. Emerson Network Power separa fato de ficção em cloud computing - IT Web.2012. Último acesso em 25 de maio de 2012. Disponível em: <http://itweb.com.br/voce-informa/emerson-network-power-separa-fato-de-ficcao-em-cloud-computing/>.