lipe ribeiro teixeira silva - versão final

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.5 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2.6 Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47



4.3 openQRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3.2 História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3.3 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51


4.3.5 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.3.6 Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52



4.4 OpenStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.4.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.4.2 História . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.4.3 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55


4.4.5 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.4.6 Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60



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.


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.


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.


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.


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


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.


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)


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.


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.


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/>.

lipe ribeiro teixeira silva - versão final

Documents