UNIVERSIDADE FEDERAL DO ABC
CENTRO DE MATEMÁTICA, COMPUTAÇÃO E COGNIÇÃO
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DA INFORMAÇÃO
RHODNEY ARTHUR MENNA BARRETO KONIG SIMÕES
GERENCIAMENTO DE ELASTICIDADE EM COMPUTAÇÃO
EM NUVEM: ESTUDO DE CASO USANDO SMART GRID
Santo André - SP
Julho de 2013
RHODNEY ARTHUR MENNA BARRETO KONIG SIMÕES
GERENCIAMENTO DE ELASTICIDADE EM COMPUTAÇÃO
EM NUVEM: ESTUDO DE CASO USANDO SMART GRID
Dissertação de mestrado apresentada ao Programa de
Pós-Graduação em Engenharia da Informação, da
Universidade Federal do ABC, como parte dos
requisitos para a obtenção do título de Mestre em
Engenharia da Informação.
ORIENTADOR: Carlos Alberto Kamienski
.
Santo André – SP
Julho de 2013
Ficha Catalográfica
S593g Simões, Rhodney Arthur Menna Barreto konig
GERENCIAMENTO DE ELASTICIDADE EM COMPUTAÇÃO EM
NUVEM: estudo de caso usando SMART GRID / Rhodney Arthur Menna Barreto
konig Simões. Santo André, S.P: UFABC, 2013.
80 f. : il. color.
Orientador: Prof. Doutor Carlos Alberto Kamienski
Dissertação (mestrado) – Universidade Federal do ABC (UFABC),
Área de Engenharia da Informação, 2013.
1.
1. SMART GRID. 2. Computação em Nuvem. 3. Gerenciamento de
Elasticidade. I. Título. II. KAMIENSKI, Carlos Alberto.
CDU 004
CDD 004.36
Este exemplar foi revisado e alterado em relação à versão original, de
acordo com as observações levantadas pela banca no dia da defesa, sob
responsabilidade única do autor e com a anuência de seu orientador.
Santo André, 18 de Outubro de 2013.
Assinatura do autor: _____________________________________
Rhodney Arthur Menna Barreto Konig Simões
Assinatura do orientador: _________________________________
Prof. Doutor Carlos Alberto Kamienski
AGRADECIMENTOS
Agradeço a Deus por ter me dado condições de lutar e alcançar os objetivos pretendidos.
Agradeço aos meus Pais pelo apoio incondicional, o que me permiti vencer os obstáculos.
Agradeço ao meu irmão, pelo incentivo e apoio em todos os momentos, mesmo distante.
Agradeço aos professores de minha graduação, que através de seus ensinamentos, permitiu
minha escalada profissional.
Agradeço em especial aos professores Jarbas Alves Cavalcante e Stênio Flávio de Lacerda
Fernandes pelo apoio no período em que estava me preparando para o mestrado.
Agradeço ao meu orientador Carlos Alberto Kamienski, pela sua excelente orientação e por
ampliar meus conhecimentos.
Agradeço a todos que de alguma forma contribuíram na minha jornada.
Agradeço por todas as coisas alegres e felizes que vivi. Agradeço também às dificuldades, estas
que me ensinaram a ver o mundo e a vida de frente, e a transformar as agruras em vitórias.
RESUMO
Computação em nuvem oferece recursos computacionais aos seus clientes na forma de serviços,
onde o provedor de nuvem cobra apenas o que o cliente usar, de maneira similar a serviços
básicos de água, energia e telefone. O cliente de nuvem possui autonomia no gerenciamento do
serviço contratado, com a possibilidade de configurá-lo para atender suas necessidades sem a
intervenção direta do provedor. Uma das principais características da computação em nuvem
para gerar flexibilidade ao usuário é a elasticidade, que possibilidade a alocação e liberação
instantâneas de recursos diante do aumento e redução da demanda. Esse tipo de gerenciamento
de recurso pode ser compreendido como uma forma de uso de computação autonômica, uma
vez que a alocação dos recursos é alterada automaticamente. O Smart Grid é uma tecnologia
para implantar uma Rede Elétrica Inteligente ainda em fase de estudo e especificação em todo
o mundo que depende em alto grau de tecnologias de informação e comunicação. Embora sua
implantação tenha um custo alto, existe um consenso de que suas vantagens superam o modelo
de comercialização de energia elétrica existente hoje, principalmente os ganhos em
sustentabilidade. Uma das propostas existentes hoje para reduzir o custo de implantação de
Smart Grid é a utilização da infraestrutura de computação em nuvem. A nuvem computacional
oferece várias características que combinam com os requisitos de Smart Grid, por ser escalável,
elástica e tolerante a falhas. Este trabalho tem como objetivo avaliar a elasticidade de
computação em nuvem com um estudo de caso em Smart Grid. Foi especificado, implementado
e avaliado parcialmente um Sistema de Gerenciador Autonômico de Smart Grid, o SGAMS
(Smart Grid Autonomic Management System). A avaliação foi realizada em nuvem privada e
em nuvem híbrida que combina a nuvem privada com o serviço de nuvem pública. O ambiente
de nuvem híbrida foi usado somente para atender os picos de demanda que superam os recursos
da nuvem privada, usando a técnica de cloudburst. Ambas utilizaram o PlanetLab para gerar
carga de trabalho assumindo o papel dos clientes de Smart Grid. As principais contribuições
deste trabalho estão na avaliação da elasticidade em um ambiente de nuvem privada e na
realização de cloudburst para a nuvem pública da Amazon AWS. Os resultados apontam que é
possível manter tempos de resposta em níveis adequados para o cenário escolhido, tanto em
nuvem pública quanto híbrida, dependendo da parametrização adotada no gerenciamento da
elasticidade.
Palavras-chave: SMART GRID. Computação em Nuvem. Gerenciamento de Elasticidade.
ABSTRACT
Cloud computing provides computing resources to its users as services, where cloud providers
charge only what clients really use, similar to basic public services such as water, energy and
telephone. Cloud clients have a good deal of autonomy for managing the services, being able
to configure it as they prefer without the direct intervention of the provider. One of the key
features that provide flexibility to cloud computing users is elasticity, which makes it possible
instant resource allocation and deallocation as demand is increased and reduced. This model of
resource management may be understood as a way of using autonomic computing, since
resource allocation is changed automatically. Smart Grid is a technology aimed at deploying an
Intelligent Power Grid that is still being studied and specified all over the world that is highly
dependent on information and communication technologies. Even though the transition to the
Smart Grid will be expensive, there is a consensus that it will bring many benefits that surmount
the current electrical energy business model, mainly when it comes to sustainability. An
alternative for deploying the needed computing resources for the Smart Grid with low cost is
the use of cloud computing, due to some important features of the latter that match the needs
of the former, such as scalability, elasticity and fault tolerance. This dissertation is aimed at
evaluating the elasticity feature of cloud computing in a scenario inspired on Smart Grid. A
Smart Grid Autonomic Management System (SGAMS) has been specified, implemented and
partially evaluated. The evaluation was conducted in both a private and a hybrid cloud, where
the latter combines private and public cloud services. A hybrid cloud environment was used for
providing additional computing power whenever demand peaks could not be dealt with by the
installed capacity of the private cloud, using the cloudburst technique. In both cloud models
PlanetLab clients were used for generating workloads playing the role of Smart Grid clients.
The main contributions of this work are results of performance evaluation of elasticity focused
on understanding the existing tradeoffs in using a private cloud as well as directing the
excessive demand to the Amazon AWS public cloud via cloudburst. Results show that it is
possible to keep response times in adequate levels for the chosen scenario, both in the private
and hybrid cloud, depending on the parameterization used for the elasticity management.
Keywords: SMART GRID. Cloud Computing. Elasticity Management.
LISTA DE FIGURAS
Figura 1 – Níveis de computação em nuvem ........................................................................... 22
Figura 2 – Componentes do controlador Nimbus[26] .............................................................. 29
Figura 3 – Arquitetura do OpenNebula contextualizada em computação em nuvem [39]. ..... 30
Figura 4 – Arquitetura do OpenStack ....................................................................................... 31
Figura 5 – Tecnologias para virtualização ................................................................................ 34
Figura 6 – Arquitetura Xen Hipervisor..................................................................................... 36
Figura 7 – Modelo conceitual de Smart Grid [8]...................................................................... 39
Figura 8 – Modelo do SGAMS ................................................................................................ 41
Figura 9 – Estrutura do XML de controle do módulo de distribuição e geração ..................... 42
Figura 10 – Arquitetura do SGAMS sem cloudburst ............................................................... 47
Figura 11 – Arquitetura do SGAMS com cloudburst .............................................................. 48
Figura 12 – Experimento com limiares positivo e negativo 250 e 100 respectivamente e sem
histerese. ............................................................................................................ 52-55
Figura 13 – Experimento com limiares positivo e negativo 400 e 125 respectivamente e sem
histerese. ............................................................................................................ 54-56
Figura 14 – Experimento com limiares positivo e negativo 600 e 150 respectivamente e sem
histerese. .................................................................................................................. 58
Figura 15 – Médias dos tempos de resposta e do número de máquinas virtuais existentes para
os experimentos sem histerese. ................................................................................ 59
Figura 16 – Experimento com limiares positivo e negativo 300, 125 respectivamente e com
histerese. ............................................................................................................ 58-60
Figura 17 – Experimento com limiares positivo e negativo 300, 125 respectivamente e sem
histerese. .................................................................................................................. 62
Figura 18 – Média do tempo de resposta e número de máquinas virtuais com histerese. ........ 63
Figura 19 – Experimento com limiares positivo e negativo 350, 150 respectivamente e com
cloudburst utilizando VMs do tipo small. ......................................................... 62-65
Figura 20 – Experimento com limiares positivo e negativo 350, 150 respectivamente e com
cloudburst utilizando VMs do tipo medium. ..................................................... 64-66
Figura 21 – Experimento com limiares positivo e negativo 350, 150 respectivamente e com
cloudburst utilizando VMs do tipo large................................................................. 68
Figura 22 – Experimento com limiares positivo e negativo 350, 150 respectivamente e sem
cloudburst. ......................................................................................................... 67-69
Figura 23 – Média do tempo de resposta e número de máquinas virtuais sem histerese e com
cloudburst. ............................................................................................................... 70
Figura 24 – Relação de custo benefício baseado no número de máquinas virtuais e tempo de
resposta .................................................................................................................... 72
LISTA DE TABELAS
Tabela 1 – Tipos de instâncias Amazon EC2 ........................................................................... 27
Tabela 2 – Lista dos recursos computacionais das máquinas utilizadas no ambiente .............. 43
Tabela 3 – Dados gerados para interpretação dos tempos de respostas ................................... 45
Tabela 4 – Estrutura da nuvem sem utilização da técnica de cloudburst ................................. 47
Tabela 5 – Estrutura da nuvem com utilização da técnica de cloudburst................................. 48
Tabela 6 – Lista de fatores e níveis utilizados nos experimentos sem cloudburst ................... 49
Tabela 7 – Lista de fatores e níveis dos experimentos adicionais sem cloudburst .................. 50
Tabela 8 – Lista de ferramentas com funcionalidades e emprego ............................................ 51
LISTA DE ABREVIATURAS E SIGLAS
AWS
CRM
EC2
Amazon Web Services
Gestão de Relacionamento com o Cliente
Elastic Compute Cloud
ERP
HPC
IaaS
IDE
MB
MPI
NIST
PaaS
PHEV
SaaS
SDK
SGAMS
SO
TI
TIC
TR
TRm
UFABC
VM
Sistemas Integrados de Gestão Empresarial
Computação de Alta Performance
Infrastructure as a Service
Ambiente integrado para desenvolvimento de software
Megabyte
Message Passing Interface
National Institute of Standards and Technology
Plataform as a Service
Híbrido Elétrico Plug-in
Software as a Service
Kit de Desenvolvimento de Software
Smart Grid Autonomic Management System
Sistema Operacional
Tecnologia da informação
Tecnologia da informação e comunicação
Tempo de resposta
Tempo de resposta mínimo
Universidade Federal do ABC
Máquina virtual
SUMÁRIO
CAPÍTULO 1 .............................................................................................................................. 16
INTRODUÇÃO ............................................................................................................................ 16
1.1. MOTIVAÇÃO ................................................................................................................. 16
1.2. OBJETIVOS ................................................................................................................... 17
1.3. CONTRIBUIÇÕES ........................................................................................................... 18
1.4. ORGANIZAÇÃO ............................................................................................................. 18
CAPÍTULO 2 .............................................................................................................................. 20
ESTADO DA ARTE ..................................................................................................................... 20
2.1
COMPUTAÇÃO EM NUVEM ........................................................................................... 20
2.1.1.
CARACTERÍSTICAS ESSENCIAIS ............................................................................... 21
2.1.2.
MODELOS DE SERVIÇOS DE NUVEM ......................................................................... 22
2.1.2.1. SOFTWARE AS A SERVICE – SAAS ............................................................................. 22
2.1.2.2. PLATFORM AS A SERVICE – PAAS ............................................................................. 23
2.1.2.2.1. GOOGLE APP ENGINE .......................................................................................... 24
2.1.2.2.2. WINDOWS AZURE ................................................................................................ 25
2.1.2.2.3. FORCE.COM .......................................................................................................... 26
2.1.2.3. INFRASTRUCTURE AS A SERVICE – IAAS ................................................................. 26
2.1.2.3.1. AMAZON EC2 ....................................................................................................... 27
2.1.2.3.3. NIMBUS ................................................................................................................. 29
2.1.2.3.4. OPENNEBULA ....................................................................................................... 30
2.1.2.3.5. OPENSTACK ......................................................................................................... 30
2.1.3.
MODELOS DE IMPLANTAÇÃO DE NUVEM ................................................................. 31
2.1.3.1. NUVEM PÚBLICA ......................................................................................................... 31
2.1.3.2. NUVEM PRIVADA ......................................................................................................... 32
2.1.3.3. NUVEM HÍBRIDA ...................................................................................................... 32
2.1.3.4. NUVEM COMUNITÁRIA ............................................................................................ 32
2.2. GERENCIAMENTO DE ELASTICIDADE .......................................................................... 32
2.3. HIPERVISOR ................................................................................................................. 34
2.3.1. Xen Hipervisor ............................................................................................................ 32
2.3.2. KVM ............................................................................................................................ 33
2.4. COMPUTAÇÃO AUTONÔMICA ...................................................................................... 37
CAPÍTULO 3 .............................................................................................................................. 39
ESTUDO DE CASO: GERENCIADOR DE SMART GRID ............................................................... 39
3.1. SMART GRID................................................................................................................. 39
3.2. VISÃO GERAL DO GERENCIADOR DE SMART GRID .................................................... 41
3.3. ARQUITETURA .............................................................................................................. 42
CAPÍTULO 4 .............................................................................................................................. 44
METODOLOGIA ........................................................................................................................ 44
4.1. PROCESSO DE COLETA NOS MÓDULOS CLIENTE E DISTRIBUIÇÃO DO SGAMS ............... 44
4.1.1.
CENÁRIO ................................................................................................................... 46
4.1.1.2. ARQUITETURA UTILIZANDO A NUVEM PRIVADA SEM CLOUDBURST ........................ 47
4.1.2.
ARQUITETURA UTILIZANDO A NUVEM PRIVADA COM CLOUDBURST ....................... 48
4.2. FATORES E NÍVEIS ........................................................................................................ 49
4.2.1.
LIMIARES UTILIZADOS NOS EXPERIMENTOS SEM CLOUDBURST.............................. 49
4.2.2.
LIMIARES UTILIZADOS NOS EXPERIMENTOS COM CLOUDBURST ............................. 50
4.3. MÉTRICAS .................................................................................................................... 50
4.4. FERRAMENTAS UTILIZADAS ......................................................................................... 51
4.5. EXPERIMENTOS ............................................................................................................ 52
CAPÍTULO 5 .............................................................................................................................. 53
RESULTADOS ............................................................................................................................ 53
5. EXPERIMENTOS SEM HISTERESE...................................................................................... 53
5.2. EXPERIMENTOS COM HISTERESE................................................................................. 59
5.3. EXPERIMENTOS COM CLOUDBURST ............................................................................. 63
5.4. CUSTO VS. BENEFÍCIO .................................................................................................. 71
CAPÍTULO 6 .............................................................................................................................. 73
CONCLUSÃO E TRABALHOS FUTUROS ..................................................................................... 73
6.1
PRINCIPAIS RESULTADOS ............................................................................................. 74
6.2. TRABALHOS FUTUROS ................................................................................................. 75
REFERÊNCIAS BIBLIOGRÁFICAS .............................................................................................. 76
16
Capítulo 1
Introdução
A computação em nuvem trouxe diversas vantagens em comparação com o ambiente
tradicional da internet. Dentre as principais podemos citar o pagamento somente pelo que é
utilizado, a elasticidade, a sensação de recursos computacionais infinitos nos provedores de
serviços. Tais características viabilizam o uso da nuvem pública para implantação de novas
soluções oriundas de Start up, sem a necessidade de grandes investimentos em infraestrutura
computacional. No entanto se faz necessária a avaliação desses serviços, mais específico o
comportamento da elasticidade para atender aos picos de consumo. Tendo em vista que tal
característica do ambiente de nuvem deve ocorrer de forma automática e transparente para o
usuário, sendo necessária apenas a configuração inicial dos limiares para a realização tanto para
a alocação de recursos quanto a liberação dos mesmos.
1.1. Motivação
O conceito de computação em nuvem é oriundo de outros conceitos já existente como:
Grid Computing [21], Utility Computing [56], onde os recursos computacionais são oferecidos
como serviço e o cliente paga somente pelo que usar, seguindo o modelo de pagamento de
serviços básicos como: água, luz e telefone. Computação em nuvem apresenta características
únicas como elasticidade, autosserviço sob demanda, amplo acesso via rede, recursos
disponíveis e medida de uso de serviço [48]. Esses atributos visam proporcionar ao cliente de
nuvem a independência deste sobre os serviços utilizados. O cliente tem a autonomia para
usufruir de todos os serviços oferecidos pelo provedor de nuvem sem a necessidade que este
intervenha. A existência de diferentes modelos de nuvem como: pública, privada, híbrida e
comunitária [48] [27], viabilizam o uso das vantagens de nuvem sem a necessidade de
abandonar a infraestrutura já existente. Desta forma o investimento necessário para utilizar o
ambiente de nuvem é reduzido, além de ser possível migrar para a nuvem pública apenas o
necessário.
O emprego de autogerenciamento, conceito oriundo de computação autonômica [30],
no ambiente de nuvem é amplamente viável, pois a complexidade existente em um data center
torna impraticável o seu gerenciamento de forma manual. Uma característica predominante das
aplicações existentes na nuvem é que em sua maioria são aplicações web. Sendo assim, o
conceito de elasticidade está acompanhado da funcionalidade de balanceamento de carga. Desta
forma é necessário não somente haver o monitoramento do ambiente de nuvem para que o
17
processo de elasticidade ocorra de forma automática. Mas como também empregar funções
como: autocura, para tolerância a falhas, e autoconfiguração, com intuito de prover ao ambiente
de nuvem a autonomia necessária para realizar a elasticidade com balanceamento de carga de
forma automática.
Para avaliar o comportamento da elasticidade em aplicações web usando a infraestrutura
da nuvem, foi construído um ambiente de gerenciamento de Smart Grid. Este é um novo modelo
para a comercialização de energia elétrica no mundo baseado na variação da tarifação diante da
oscilação do consumo. Tal conceito visa ampliar a utilização de fontes renováveis e estimular
o consumo consciente por parte do cliente. Para tanto Smart Grid será totalmente digital,
necessitando de recursos integrados de processamento, transmissão e gerenciamento de dados
em tempo real da rede de energia elétrica [13]. Para que o objetivo de conscientizar os
consumidores seja alcançado é necessário disponibilizar informações sobre a produção,
transmissão e consumo de energia tanto para as produtoras quanto para o consumidor em sua
casa, estas informações são imprescindíveis para que o consumidor possa usar este recurso de
forma mais econômica, que saberá em qual hora do dia será mais barato usar um determinado
aparelho que irá consumir mais energia. Porém para implantar tal tecnologia diversos desafios
são apresentados. Entre eles podemos citar o alto custo de implantação tanto da infraestrutura
de transmissão de energia elétrica quanto de TI para fornecer as informações e a falta de padrão
entre as concessionárias para disponibilizar as informações para os clientes.
O Smart Grid, o Smart Grid Autonomic Management System – SGAMS é ambiente de
gerenciamento de Smart Grid usado para avaliação da elasticidade neste trabalho. São
utilizados dois ambientes distintos, o primeiro visa avaliar apenas a nuvem privada com o
controlador de nuvem OpenNebula. Já o segundo tem como objetivo empregar o conceito de
cloudburst [32], utilizando a nuvem pública para atender as requisições quando os recursos da
nuvem privada já estiverem exauridos. Para tanto foi usada a nuvem pública da Amazon WS,
com o serviço EC2.
1.2. Objetivos
O objetivo geral deste trabalho de pesquisa é avaliar o comportamento da elasticidade
em ambiente de nuvem computacional, privada ou híbrida, com um estudo de caso no
gerenciamento de Smart Grid. O trabalho visa obter maior compreensão sobre as relações de
compromisso (trade-off) e a relação custo/benefício das escolhas em relação a qualidade e
custo.
Os objetivos específicos são:
18

Identificar a implicação da variação dos limiares para a elasticidade no aumento e
diminuição do tempo de resposta das requisições.

Elucidar o efeito de utilizar um ambiente de nuvem privada em comparação com outro
ambiente que faça uso de cloudburst para a nuvem pública da Amazon WS.

Demonstrar o resultado ao fazer uso de histerese para controlar a elasticidade em um
ambiente de nuvem privada.

Identificar uma forma de calcular o custo benefício entre investimento em recursos
computacionais e diminuição do tempo de resposta.

Elucidar as implicações da escolha dos diferentes tipos de instâncias na nuvem pública
da Amazon WS para elasticidade no tempo de resposta das requisições.
1.3.
Contribuições
As principais contribuições do trabalho são:

Especificação, implementação e avaliação do comportamento da elasticidade em um
ambiente de nuvem computacional em um ambiente globalmente distribuído.

Identificação dos melhores limiares para efetuar a elasticidade em um ambiente de
nuvem privada e híbrida (com cloudburst) para o ambiente de Smart Grid.

Elucidação do reflexo do tipo de instância escolhida na Amazon WS para elasticidade
no tempo de resposta das requisições.

Impacto dos diferentes tipos de instâncias da nuvem pública no investimento em
recursos computacionais para a elasticidade.

Elucidação da maneira de se calcular o custo benefício entre investimento em recursos
computacionais e diminuição do tempo de resposta
1.4. Organização
A dissertação está organizada da seguinte forma. No Capítulo 2, são apresentadas as
informações necessárias para contextualizar o leitor ao tema abordado no trabalho.
Sucessivamente, no Capítulo 3, é descrito o estudo de caso empregado neste trabalho,
juntamente com a contextualização de Smart Grid para o ambiente de nuvem.
No Capítulo 4, é descrita a metodologia utilizada na pesquisa. Assim como a arquitetura
do gerenciador do Smart Grid bem como os cenários em que este foi implantado. São descritas
as métricas e a maneira como foram realizados os experimentos.
No Capítulo 5, são apresentados os resultados obtidos, onde é feita uma discussão sobre
as implicações dos experimentos. O custo benefício entre utilizar a nuvem privada com
19
diferentes limiares para a elasticidade e a possibilidade de cloudburst para a nuvem pública da
Amazona WS.
No Capítulo 6, conclui-se a dissertação com uma breve descrição do trabalho realizado
e suas principais contribuições além dos trabalhos futuros.
20
Capítulo 2
Estado da Arte
Neste capítulo, são apresentadas as informações necessárias para contextualizar o leitor
quanto ao tema abordado e, assim, proporcionar um melhor entendimento dos capítulos
subsequentes deste trabalho. As seções estão distribuídas da seguinte forma: na seção 2.1 é
apresentado o conceito de computação em nuvem, seus tipos, níveis e exemplos para facilitar a
compreensão do leitor. Na seção 2.2 são descritos os monitores de máquinas virtuais e como
cada um funciona. Na seção 2.3 é feita uma rápida descrição de computação autonômica e seus
aspectos. Por fim na seção 2.4 é feita a descrição de Smart Grid e suas vantagens perante a
infraestrutura vigente.
2.1 Computação em Nuvem
Serviços essenciais de utilidade pública, como por exemplo, eletricidade, água, esgoto
e telefone são entregues à população de modo bastante transparente e o usuário paga apenas
pelo que efetivamente consome. Aplicando a mesma lógica de negócio na informática, esse
modelo possibilita que serviços de TI sejam oferecidos aos usuários sob demanda, onde estes
pagam apenas pelo que utilizaram do serviço. Essa é a ideia básica da Computação em Nuvem,
que provê recursos dinamicamente escaláveis e normalmente virtualizados através de serviços
sobre a Internet [7]. Segundo esse modelo, desenvolvedores com ideias inovadoras de serviços
na Internet não precisam mais investir muito capital em hardware e em recursos humanos para
manter o serviço em operação. Mais do que isso, companhias que necessitam de um alto poder
de processamento podem obter seus resultados tão rapidamente quanto seus programas possam
ser dimensionados, uma vez que usar mil servidores por uma hora pode custar o mesmo que
usar um único servidor por mil horas. Essa elasticidade de recursos, sem a necessidade de pagar
mais por usar poder computacional em alta escala, é inédita na indústria da TI [7]. Do ponto de
vista do usuário, infraestruturas de computação em nuvem disponibilizam sistemas
operacionais que possibilitam que os usuários, utilizando qualquer dispositivo conectado à
Internet, possam ter acesso aos serviços, arquivos, informações e programas situados “na
nuvem”. Assim, os dispositivos utilizados pelos usuários não necessitam de grandes recursos
computacionais, aproximando-se de simples terminais.
21
Existem quatro [49] [27] categorias distintas de nuvens, públicas, privadas, híbridas e
as comunitárias. Empresas que oferecem serviços de algum nível de computação em nuvem
para os seus clientes são classificadas como nuvens públicas. Já nuvens privadas são
construídas pelas organizações para atender necessidades específicas de sua empresa, sendo
necessário gerenciar a infraestrutura física para suprir tais requisitos. No caso das nuvens
híbridas estes surgem da composição tanto de nuvens públicas quanto privadas, tal divisão
geralmente ocorre com intuito de delegar as empresas que provem serviços, parte das tarefas
que poderiam ser executadas em um ambiente externo ao das empresas.
Computação em nuvem prover serviços de diferentes níveis e finalidades como [49]
[27]: Infraestrutura as a Service (IaaS), Plataforma as a Service (PaaS) e Software as a Service
(SaaS) [39]. IaaS tem como objetivo oferecer infraestrutura de hardware para organizações
configurarem todo o seu ambiente de software de forma flexível e escalável. PaaS tem por
finalidade prover uma plataforma de desenvolvimento, teste e o ambiente de implantação do
software, visando atender parte do ciclo de vida do software. Já no escopo de SaaS a intenção
é proporcionar para o usuário, seja ele empresa ou consumidor final, um software que atenda
as suas necessidades sem que haja a preocupação com o local onde este esteja instalado.
2.1.1. Características Essenciais
Segundo NIST[48][40][35] computação em nuvem possui características que a lhe
distingue de outros conceitos já existentes, como Grade Computacional (Grid Computing) [21].
As características essenciais de computação em nuvem são:

Autosserviço sob demanda: Um consumidor pode aumentar ou diminuir os recursos
computacionais contratados sem a necessidade da intervenção do provedor de serviços.

Amplo acesso via rede: Os recursos da nuvem devem estar disponíveis para serem
acessados pelos diferentes tipos de dispositivos, tais como: celular, tablete, notebook,
PCs etc.

Recursos disponíveis: Os recursos providos pelo prestador de serviço podem ser do tipo:
enlace de rede, CPU, memória, armazenamento dentre outros. Todos esses recursos são
alocados e liberados dinamicamente para o cliente diante da sua necessidade. O cliente
não possui conhecimento da localização exata dos recursos disponíveis como tão pouco
controle sobre o mesmo, o que em grande parte é fornecido ao cliente é a escolha do
data center em que os recursos serão alocados.
22

Elasticidade: Capacidade de o cliente alocar mais recursos computacionais para atender
a um pico de demanda, esta característica pode ser atendida de forma automática como
é provido pela Amazon WS com o serviço CloudWatch [4], onde este monitora diversas
métricas personalizáveis pelo cliente.

Medida de uso de serviço: Os provedores de serviço de nuvem utilizam de diferentes
métricas para quantificar, monitorar e reportar a utilização dos recursos de forma
transparente tanto para o cliente quanto para o próprio provedor.
2.1.2. Modelos de serviços de nuvem
Computação em nuvem apresenta diversos níveis de serviços, no entanto os três níveis
amplamente adotados pela academia são os de Software as a Service, Platform as a Service e
Infrastructure as a Service [59][49][40]. Ordenados seguindo uma arquitetura hierárquica, onde
quanto mais alta a camada maior será a abstração do hardware e dos ambientes de
desenvolvimento, IDEs, configurações de rede, gerenciamento de recursos, (Figura 1).
Figura 1 – Níveis de computação em nuvem
2.1.2.1. Software as a Service – SaaS
Software como serviço [11] é a camada mais alta dos serviços providos por computação
em nuvem (Figura 1). Neste modelo de negocio o serviço é disponibilizado utilizando a
infraestrutura de nuvem com intuito de proporcionar maior disponibilidade. Por ser um serviço
web não existe a necessidade de instalação/configuração da aplicação na infraestrutura do
23
cliente, reduzindo o custo final do serviço. O software é utilizado apenas através de um browser,
tal recurso se mostra vantajoso devido a facilidade de upgrade da aplicação sem que haja a
necessidade de intervenção em qualquer máquina cliente. Todas as atualizações são efetuadas
diretamente na aplicação existente no servidor web e automaticamente ficarão disponíveis para
os diversos clientes.
Atualmente, diversas aplicações estão sendo migradas para este novo modelo de
negócio. Dentre elas se destacam o Google Docs, onde aplicativos de escritório como: editores
de texto, planilhas, apresentações são oferecidos gratuitamente por meio da nuvem e
apresentam um alto grau de qualidade. Outro serviço que se consolidou no meio empresarial
foi a Salesforce.com [61] com o serviço de Enterprise Resource Planning – ERP online. Neste
mesmo serviço é integrada uma plataforma de desenvolvimento para que as empresas possam
implementar módulos para atender necessidades específicas que o ERP não possui. Tal
plataforma é enquadrada no nível de Platform as a Service – PaaS que é descrito abaixo.
O crescente avanço no desenvolvimento de tecnologias para a implementação de
interfaces de usuário para aplicações web como Flash, AJAX e HTML5 impulsionou a ampla
utilização de SaaS. Pois à medida que as aplicações web apresentam funcionalidades
semelhantes às aplicações desktop aumenta a adesão de novos adeptos a esse novo paradigma,
devido à facilidade do usuário se adaptar à nova aplicação. Outro fator importante no emprego
deste novo paradigma é a utilização de protocolos para integração de serviços como SOAP e
REST. Ambas as tecnologias visam a adaptação/integração de aplicações existentes visando à
redução do custo de desenvolvimento de novas aplicações.
2.1.2.2. Platform as a Service – PaaS
Plataforma como serviço [11] é uma das categorias dos serviços providos por
computação em nuvem. Neste nível de serviço são fornecidas algumas etapas no processo de
desenvolvimento de software. Iniciando pelo ambiente de desenvolvimento da aplicação, em
seguida, pela fase de depuração e teste e culminando na implantação, execução e o
gerenciamento. Estas características visam reduzir custos com o ciclo de vida do software e
com a configuração tanto do ambiente para desenvolvimento quanto para o local de
implantação, tornando possível também a redução do tempo de desenvolvimento da aplicação.
Os softwares desenvolvidos utilizando PaaS frequentemente são aplicações Webs, no entanto
existem exceções. Assim como as ferramentas usadas para a implementação podem ser online,
obrigando o desenvolvedor estar conectado para trabalhar, ou off-line permitindo o
24
desenvolvimento local e após a implementação que será realizada a sincronização com os
servidores do provedor de serviço.
Atualmente existem algumas plataformas que se destacam em relação às demais como
Google App Engine [24], Microsoft Azure [38] e Force.com [20]. Cada um desses ambientes
possui características que as distinguem quanto ao objetivo de sua plataforma, tanto a suporte
a linguagens como em ambiente de desenvolvimento. Caso nenhuma das plataformas existentes
atenda as necessidades específicas de cada negócio, é possível a construção de uma plataforma
própria utilizando o nível de Infraestrutura como Serviço (IaaS) [52] para suprir tal exigência.
No entanto todas as plataformas de nuvem devem, além das funcionalidades supracitadas,
prover uma abstração do ambiente em que está sendo utilizado para o desenvolvimento, como
sistema operacional e recursos de rede [7].
Devido ao novo paradigma apresentado por serviços de plataformas surgem
questionamentos quanto à migração de sistemas já consolidados nas empresas. A migração de
todos os dados é uma tarefa extremamente custosa e delicada, para tanto existe o conceito de
ambientes híbridos. Onde parte da infraestrutura fica localizada na própria empresa e outra parte
é levada para a nuvem, ambos os sistemas executam tarefas de forma sincronizada para garantir
a integridade dos dados [7]. Fatores como custo para mover a aplicação para a nuvem, a
necessidade de um hardware para executar a aplicação além de ser preciso analisar se a
aplicação atende aos requisitos necessários para ser implantada na nuvem. Como por exemplo,
se o sistema necessita de intervenção humana para a sua reinicialização, caso necessário.
2.1.2.2.1. Google App Engine
O Google App Engine [24] é uma plataforma que prove o desenvolvimento de
aplicações tradicionais web. Tal ambiente fornece ao desenvolvedor uma abstração das
camadas tanto de recursos físicos quanto de armazenamento [12]. O desenvolvedor não precisa
se ater a recursos de armazenamento, rede e CPU, aumentando assim a eficiência no
desenvolvimento da aplicação, pois a própria plataforma escalona e balanceia a carga de acordo
com a demanda de cada aplicação implantada em sua infraestrutura. Na camada de
armazenamento é utilizado o MegaStore [6] que se baseia em BigTable [16]. Essa tecnologia é
empregada no gerenciamento de grandes quantidade de dados (Big Data), que possui recursos
de autogerenciamento o tornando assim tolerante a falhas.
A plataforma do Google oferece suporte a três linguagens de programação Java, Python
e Go, sendo essa última uma linguagem da própria Google. O desenvolvimento seja ele em
qualquer uma das linguagens supracitadas, se dá por meio de um Software Development Kit –
25
SDK que é instalado no Eclipse por meio de um plug-in. Após a implementação e teste da
aplicação, que são realizados localmente por meio do SDK instalado, é feita a implantação na
infraestrutura do Google.
Todas as aplicações presentes na infraestrutura do Google estão restritas a cotas de
utilização. Essas cotas são referentes a uso de disco rígido, tráfego de entrada e saída e tempo
de processamento. O Google apresenta uma tabela de preços para o excedente das cotas de cada
recurso, até mesmo destinatários de e-mails. No entanto o serviço oferecido gratuitamente
apresenta resultados satisfatórios.
2.1.2.2.2. Windows Azure
O Windows Azure [31] assim como o Google App Engine prove os recursos e
funcionalidades esperadas de um PaaS. Este serviço fornece recursos de rede, CPU,
armazenamento, gerenciamento de aplicações na internet por meio do data center da própria
Microsoft, entre outros sob a demanda da necessidade do cliente sendo escalável e tolerante a
falhas. Windows Azure oferece para a camada de armazenamento o Microsoft SQL Azure que
é construído sobre a tecnologia SQL Server, banco de dados da própria Microsoft, sendo este
um banco de dados relacional.
Esta plataforma de desenvolvimento da Microsoft oferece suporte a diversas linguagens
de programação como: Java, Ruby, .NET Framework, C# e PHP, além de possuir
compatibilidade com REST, SOAP, XML. Diante das características de abstração que um PaaS
deve apresentar o Windows Azure provê tais requisitos em forma virtualizada utilizando
máquinas virtuais, virtualização de rede.
A plataforma da Microsoft usa o componente central Controlador de Fábrica - FC sendo
este extremamente redundante, pois tem como funcionalidade gerenciar e automatizar todo o
ciclo de vida do hardware e software utilizado para executar uma determinada tarefa. Para a
gerência de hardware, o FC controla a alocação e a liberação de recursos, máquinas virtuais,
infraestrutura de rede, diante do software em execução, além de se auto recuperar diante de uma
falha sem que seja necessária a intervenção de um especialista. Já para gerenciamento de
software, o FC tem como responsabilidade um repositório com todas as aplicações em
execução, onde ele dimensiona uma máquina virtual, configura filtros de pacotes diante da
necessidade de recursos dessa aplicação. O FC também auxilia a aplicação a se recuperar de
uma falha automaticamente.
26
2.1.2.2.3. Force.com
A Salesforce.com [37] foi a pioneira no mercado de Enterprise Resource Planning ERP e Customer Relationship Management - CRM online oferecendo serviços no nível de
SaaS. No entanto, ela observou que cada cliente possui uma necessidade específica de seu
negócio, sendo necessário o desenvolvimento de funcionalidades específicas para atender essas
necessidades. Diante dessa problemática, a Salesforce.com aumentou o seu portfólio com a
adição da plataforma Force.com [7]. Sendo este ambiente capaz de desenvolver e incorporar as
aplicações aos serviços providos pela Salesforce.com.
O ambiente de desenvolvimento é instalado por meio de um plug-in para o Eclipse e a
única linguagem a qual oferece suporte é Java. As aplicações a serem implementadas nesse
ambiente seguem o padrão de projeto MVC, para a futura implantação e customização da
solução já existente.
2.1.2.3. Infrastructure as a Service – IaaS
No nível de Infraestrutura como serviço – IaaS [39], hardwares são providos sob
demanda, sem que haja a necessidade de um contrato de longo prazo entre o cliente e o provedor
de serviço. Tais recursos podem ser oferecidos por meio de armazenamento, rede além de
softwares específicos como sistemas operacionais e serviços de balanceamento de carga.
Grande parte destes serviços é provida pelos gerenciadores de máquinas virtuais – Hipervisor,
pois estes realizam efetivamente a virtualização nos data centers. Com o intuito de tornar a
infraestrutura existente flexível é amplamente utilizado o recurso de virtualização.
Consequentemente viabiliza a elasticidade para alocar e liberar recursos computacionais com a
finalidade de atender aos picos de consumo das aplicações. Para tanto, tecnologias como Xen
Hipervisor que possuem funcionalidades como para-virtualização se destacam pelo melhor
desempenho [28].
Este serviço apresenta ser atraente para empresas que visam não possuir uma
infraestrutura computacional robusta para suportar as aplicações existentes na empresa. Com a
utilização
dos
serviços
de
IaaS
as
empresas
delegam
a
responsabilidade
de
gerenciamento/monitoramento dos hardwares para os provedores de IaaS, consequentemente
deixam de investir em manutenção. Os provedores deste nível de serviço de nuvem agregam
valor aos serviços prestados oferecendo outros serviços como: balanceamento de carga, onde
diante do aumento do consumo mais máquinas virtuais serão alocadas automaticamente e
liberadas quando houver a redução do consumo. Além de possuírem serviços de persistência e
uma grande variedade de configuração de máquinas virtuais. As mais econômicas com 613 MB
27
de RAM e 1 core de 1Ghz, e as máquinas mais robustas com 15GB e 8 cores de processamento.
Existindo ainda instâncias clusters que ultrapassam os 60 GB de RAM e 88 cores, tais máquinas
são indicadas para aplicativos High Performance Compute – HPC.
Uma alternativa às soluções oferecidas pelos provedores de nuvem são os controladores
de nuvem como OpenNebula, Nimbus, Eucalyptus dentre outros [45][65][63]. Estas
ferramentas proporcionam ao usuário criar sua nuvem em sua própria infraestrutura. Com
intuito de oferecer serviços semelhantes aos dos provedores de nuvem estes controladores
demonstram ser bastante viáveis. Para empresas que não querem descartar a infraestrutura já
existente, mas querem usufruir das funcionalidades das nuvens, esses controladores suprem esta
necessidade de mercado e acadêmico.
2.1.2.3.1. Amazon EC2
A nuvem pública que fara parte do protótipo a ser desenvolvido é a da Amazon Web
Service (AWS) [3], por ser uma das maiores empresas provedoras de infraestrutura como
serviço (Infrastructure-as-a-Service - IaaS) no mundo, por possuir um grau de confiabilidade
satisfatório, por deter um data center geograficamente próximo, e desta forma, ser apto a
hospedar mais adequadamente a avaliação. Especificamente, foi avaliado o serviço Amazon
Elastic Compute Cloud (Amazon EC2) [2], que é um serviço de IaaS que possibilita a utilização
da grande infraestrutura computacional da Amazon pelos clientes. Esse serviço é chamado de
elástico porque permite que os clientes aumentem ou diminuam sua utilização dinamicamente
através da criação ou remoção de instâncias de máquinas virtuais.
A Amazon EC2 oferece alguns padrões de instâncias virtuais a serem alocadas para o
cliente – como pode ser contemplado na (Tabela 1). Além dos padrões de instâncias
apresentados na tabela, existem outras instâncias de alto desempenho que estão disponíveis
apenas para algumas centrais de servidores disponibilizados pela Amazon. É utilizado o
conceito de unidades de processamento EC2 – ECU, que é correspondente a capacidade de um
processador Opteron 2007 ou Xeon 2007 de 1.0-1.2 GHz.
Tabela 1 – Tipos de instâncias Amazon EC2
Tipo de
Memória
Armazenamento
Instância
Unidades de
Plataforma
Preço/Hora
$0,020 $0,027
$0,060 $0,080
Processamento
Micro
613 MB
Variável
Até 2 ECUs
32 bits / 64 bits
Pequeno
1,7 GB
160 GB
1 núcleo virtual
com 1 unidade
EC2 Compute
32 bits/ 64 bits
28
Médio
3,75 GB
410 GB
Grande
7,5 GB
850 GB
Extragrande
15 GB
1.690 GB
1 núcleo virtual
com 2 unidades
de
processamento
EC2
2 núcleos
virtuais com 2
unidades de
processamento
EC2 cada
4 núcleos
virtuais com 2
unidades de
processamento
EC2 cada
32 bits/ 64 bits
$0,120 $0,160
64 bits
$0,240 $0,320
64 bits
$0,480 $0,640
2.1.2.3.2. Eucalyptus
O Eucalyptus[43] é um controlador de nuvem que possui duas soluções, uma
proprietária e outra de código aberto para a construção de IaaS. Esta ferramenta era a mais
popular dentre os controladores de nuvem, pois se destacava por possuir uma arquitetura
dividida em módulos simples e distribuída hierarquicamente. Por ser descentralizado o
Eucalyptus possibilita a criação de nuvens escaláveis e distribuídas. Os módulos específicos
para gerência de máquinas virtuais e de armazenamento podem ser alocados em servidores
distintos, o que possibilita a criação de infraestruturas dedicadas a uma única tarefa em
particular. Tal característica pode resultar em um melhor desempenho devido ao não
compartilhamento de recursos.
No entanto, o motivo pelo qual tornava o controlador de nuvem Eucalyptus popular era
possuir uma interface de acesso aos serviços baseados na API da Amazon EC2. É possível
desenvolver aplicações que utilizem o Eucalyptus em um determinado momento e em seguida
utilize a própria infraestrutura da Amazon EC2, sem que haja a necessidade de alteração de
grande parte do código. Além de permitir a utilização tanto do Eucalyptus quanto da Amazon
EC2 simultaneamente, fazendo-se uso da mesma API.
Porém, o fator que desmotivou o seu uso perante os demais controladores de nuvem foi
a falta de atualizações e manutenção da solução de código aberto priorizando a solução
empresarial. E o surgimento de padrões de interfaces para serviços de IaaS, sejam elas abertas
ou de provedores, como OCCI [44] além dos demais controladores de nuvem também passarem
a oferecer suporte a API da Amazon EC2.
29
2.1.2.3.3. Nimbus
O Nimbus [42] é uma plataforma de IaaS específica para usuários de aplicações
científicas. Este controlador oferece a funcionalidade de contratar recursos de outras nuvens
como a Amazon EC2 e até mesmo de outros controladores de nuvem. Tal característica se
apresenta relevante por tornar transparente para o usuário o local físico da máquina virtual que
está instanciando. No entanto este controlador possui limitações quanto ao sistema de
armazenamento, pois o Nimbus só há suporte ao próprio sistema de armazenamento intitulado
Cumulus. Devido ao seu objetivo de simplificar e facilitar a sua utilização é consideravelmente
reduzido o número de parâmetros a ser definido pelo usuário, o que impõe severas limitações
de recursos comparados aos demais controladores.
Os componentes de sua arquitetura interna (Figura 2), cada componente de sua estrutura
são responsáveis por uma funcionalidade distinta [50].

Workspace service: este módulo é responsável pelas interfaces EC2 e WSRF ambas
baseadas em Web services, é atribuído a este componente a funcionalidade que prove
segurança por meio de autenticação e autorização utilizando GSI.

Workspace control: este componente é responsável por criar e gerenciar as máquinas
virtuais além das imagens referenciadas para a criação das MVs. Este módulo recebe
como atribuição também a alocação dos IP das máquinas recém-criadas. Este
controlador possui suporte aos gerenciadores de máquinas virtuais Xen Hipervisor e
KVM [33].

Workspace resource management: este módulo possui a funcionalidade de gerenciar
máquinas virtuais de outros controladores como o OpenNebula.

Workspace pilot: este último componente é responsável por prover virtualização em um
cluster sem que haja a necessidade de mudanças severas no mesmo.
Figura 2 – Componentes do controlador Nimbus[29]
30
2.1.2.3.4. OpenNebula
O OpenNebula [64][68] é um controlador de nuvem que possui uma arquitetura com
alto grau de centralização e flexível. Além de apresentar como ponto forte a sua customização,
possibilitando ao usuário definir a maneira como o OpenNebula deverá ser executado diante
das tarefas a serem executadas. Devido à customização, este controlador se torna adaptável e
com características de interoperabilidade, podendo assim ser executado em diferentes data
centers. Por ser uma ferramenta de código aberto, os seus módulos apresentam grande
integração com softwares de armazenamento já existentes no ambiente.
O controlador de nuvem OpenNebula possui alto grau de personalização comparado aos
demais controladores. Esta característica resulta em uma grande complexidade para efetuar de
forma vantajosa as configurações deste controlador, sendo assim se faz necessário a presença
de um técnico para desempenhar tal tarefa. A arquitetura do OpenNebula é baseada em três
tecnologias para permitir a provisão de serviços em nuvem: virtualização, armazenamento e
rede (Figura 3). Por ser de uma camada superior na hierarquia de virtualização, o OpenNebula
pode controlar o uso de diferentes hipervisors. Dentre eles está presente o Xen Hipervisor,
ferramenta utilizada entre todos os controladores de nuvem e até mesmo em provedores de
nuvem como a Amazon EC2.
Figura 3 – Arquitetura do OpenNebula contextualizada em computação em nuvem [46].
2.1.2.3.5. OpenStack
O OpenStack [47][68] é um sistema operacional em nuvem que controla grandes
recursos computacionais, como: processamento, armazenamento e recursos de rede, ao longo
de um data center, tudo gerenciado através de uma interface web. O OpenStack foi criado a
partir da parceria entre Rackspace [54], uma das maiores provedoras de serviços de nuvem, e a
31
NASA. Cada uma dessas organizações contribuiu significativamente para o projeto, resultando
na arquitetura composta por três partes (Figura 4): o Nova, oriundo do Nebula da NASA este
responsável por implementar a parte computacional da arquitetura do OpenStack - Compute. O
Swift, proveniente do Cloud Files da Rackspace responsável pelo gerenciamento de
armazenamento e o Glance tendo como atribuição a imagens a serem utilizadas para a criação
das máquinas virtuais [67].
Figura 4 – Arquitetura do OpenStack
2.1.3. Modelos de implantação de nuvem
As nuvens podem ser classificadas diante da infraestrutura física as quais pertencem.
Variando desde poucos servidores localizados dentro de uma determinada instituição para
atender necessidades específicas da própria instituição. Existe grandes data centers
estabelecidos em diversas localidades do mundo para atender as necessidades de seus clientes.
Existem quatro [11][35][49] modelos de nuvens sendo elas: pública, privada, híbrida e
comunitária.
2.1.3.1. Nuvem Pública
As nuvens públicas são oferecidas por provedores de serviços, sejam eles no nível de
SaaS, PaaS e IaaS para seus clientes/usuários. Apesar dos provedores disponibilizarem os
serviços para os clientes/usuários, não significa que estes sejam pagos. Neste modelo de
negócio o custo da disponibilização do serviço pode ser feita tanto em forma de cobrança direta
ao seu cliente, ou em forma de anúncios para os usuários [11]. Geralmente os provedores de
IaaS e PaaS utilizam da cobrança direta, já em SaaS é mais frequente por meio de anúncios
salvo as exceções de sistemas empresarias como Salesforce.
32
2.1.3.2. Nuvem Privada
Os serviços oferecidos pelas nuvens privadas são executados dentro da própria
infraestrutura da empresa usuária do serviço. Tal categoria de nuvem é proveniente da opção
de não migrar a infraestrutura já existente para a nuvem pública, mas mesmo assim usufruir dos
recursos oferecidos pela nuvem por meio da utilização dos controladores de nuvem. No entanto,
a escolha de não migrar para a nuvem pública acarreta no custo de efetuar manutenção e
upgrade sempre que necessário [35].
2.1.3.3. Nuvem Híbrida
A nuvem híbrida é composta pelas nuvens públicas e privada, tal fato ocorre quando
uma determinada organização decide não migrar totalmente sua infraestrutura para a nuvem
pública, dessa forma as duas infraestruturas executam tarefas em paralelo [51]. Outra aplicação
seria quando são utilizados os serviços providos pela nuvem pública para atender a um pico de
consumo de seus clientes. A funcionalidade de utilizar a nuvem pública quando não existem
mais recursos na nuvem privada, através da elasticidade, é denominado cloudburst [32]1.
2.1.3.4. Nuvem Comunitária
A nuvem comunitária visa distribuir tanto os custos quanto a gestão entre as
organizações que compõem a nuvem. Tal categoria de nuvem surge a partir de objetivos e
interesses semelhantes de seus integrantes [11], um exemplo similar de tal tipo de nuvem é o
PlanetLab [53]. No entanto conceitualmente em computação em nuvem o usuário/cliente não
possui conhecimento da localização geográfica dos servidores, já o PlanetLab não prove essa
transparência para o usuário/cliente.
2.2. Gerenciamento de Elasticidade
O conceito de elasticidade em nuvem segundo NIST [48] emprega a liberdade do cliente
de alocar e liberar recursos diante da sua necessidade, sem que seja necessária a intervenção do
provedor de serviço. No entanto, os recursos estarem apenas disponíveis quando necessário não
é suficiente, estes recursos devem possuir a característica de alta disponibilidade. Tal atributo
implica em um nível adequado de serviço 24 horas por dia e 7 dias por semana (7/24), com
O termo cloudburst em inglês pode ser traduzido por “aguaceiro” em português. Como esta traduação não
auxilia o processo de compreensão do conceito de cloudburst no contexto de Computação em Nuvem, neste
trabalho será utilizado o termo original em inglês.
1
33
apenas alguns minutos de instabilidade por ano [18]. É possível categorizar os mecanismos de
elasticidade [22].
A elasticidade pode ser feita de forma automática na nuvem pública da Amazon WS por
meio do serviço CloudWatch. Outros provedores de nuvem pública como GoGrid [23] e
Rackspace [54] apresentam serviços de replicação. Porém estas funcionalidades não são
oferecidas nativamente, sendo necessária a implementação por meio de APIs. O CloudWatch
tem como funcionalidade monitorar métricas como: utilização de CPU e memória, quantidade
de requisições que são efetuadas para uma determinada máquina virtual. Diante dessas métricas
o cliente pode configurar limiares para que uma nova VM seja criada para atender a demanda.
No entanto, este recurso não é viabilizado por controladores de nuvem privada como
OpenNebula, por tanto se o cliente de nuvem privada quiser usufruir de tal funcionalidade ele
terá de implementar este recurso.
A utilização de nuvem híbrida pode fornecer um ambiente robusto o suficiente para
suportar picos de demanda. No entanto, o uso da nuvem pública reflete no aumento do
investimento em infraestrutura. O emprego da técnica cloudburst [32] é relevante para a
redução do custo com infraestrutura sem ter a redução da qualidade do serviço. Pois somente
serão criadas novas máquinas virtuais na nuvem pública quando os recursos existentes na
nuvem privada já tiverem se exaurido. Desta forma não haverá o uso da nuvem pública a menos
que seja realmente necessária a sua utilização. Para a utilização de tal técnica se faz necessário
o conhecimento dos diferentes tipos de máquinas virtuais nas nuvens públicas. Pois cada tipo
possui preço e recursos computacionais distintos, identificar a que oferece melhor custo
benéfico é de suma importância para não investir mais do que o necessário e não perder a
qualidade do serviço prestado. Outro fator a ser considerado é o data center em que será
implantada as VMs criadas, tendo em vista a variação do preço do mesmo tipo de instância para
diferentes data centers.
O trabalho realizado em [57] propõe a utilização de um framework que tem como
objetivo executar aplicações do tipo HPC – Computação de alta performance, usando o padrão
para comunicação de dados em computação paralela MPI no ambiente de nuvem pública da
Amazon. Para tanto foi criado um módulo específico onde o usuário determina o limite de
utilização, baseando-se no tempo a ser usado e no quanto será investido financeiramente. Porém
estas métricas não garantem que ao atingir um dos limiares o resultado da operação tenha sido
alcançado. Este trabalho apresenta severas limitações, tendo em vista o seu escopo, HPC
utilizando um padrão específico MPI.
34
O trabalho [55] assim como no anterior, é focado em aplicações que utilizem
computação paralela por meio do padrão MPI. Foi utilizado o framework Work Queue [34],
sendo este baseado no paradigma master-worker, onde o master tem como responsabilidade
gerenciar todos os worker e este possui como atribuição executar a tarefa que lhe designada.
Ao contrário do artigo anterior neste trabalho não apresentou uma forma de determinar o quanto
gostaria de ser investido na nuvem pública. Elas utilizaram a nuvem da Amazon e Microsoft
Azure para a realização dos experimentos, tendo como objetivo comparar desempenho.
O trabalho realizado nesta dissertação tem como o foco aplicações web, ao contrário
dos trabalhos supracitados. Foram utilizadas duas variáveis de limiares para efetuar a
elasticidade. Estes limites são baseados na métrica de número de requisições simultâneas, pois
esta apresenta maior confiabilidade para evitar a ação da elasticidade de forma desnecessária.
Todo o processo se dá de forma automática, não só a elasticidade como o conceito implícito de
balanceamento de carga.
2.3. Hipervisor
São responsáveis por realizar efetivamente a virtualização nos servidores, permitindo
esses a criação de várias máquinas virtuais em uma única máquina física. Existem três
tecnologias distintas utilizadas pelos VMM para prover a virtualização [36][41][69] (Figura 5):
virtualização total, para-virtualização e a virtualização no nível de sistema operacional.
( a ) Virtualização total
( b ) Para-virtualização
( c ) Virtualização no nível de sistema operacional
Figura 5 – Tecnologias para virtualização
35

Virtualização total: Este tem como característica fornecer ao sistema operacional da
máquina virtual todos os recursos da máquina física. Sendo assim o SO não necessita
de nenhuma alteração. Porém, esta tecnologia apresenta graves problemas, o mais
impactante é a necessidade do VMM testar todas as instruções a serem executadas antes
de efetivamente as realizarem. Pois algumas delas podem alterar o estado do sistema,
tendo em vista que o sistema operacional instalado na máquina virtual não possui o
conhecimento do ambiente em que está sendo executado [36].

Para-virtualização: Esta tecnologia visa resolver os problemas existentes na
virtualização total. Para tanto se faz necessário que os sistemas operacionais a serem
controlados pelo monitor de máquinas virtuais sejam modificados. Com intuito de não
haver a necessidade de testar as tarefa que irão mudar o estado do sistema, o próprio
sistema operacional sinaliza ao VMM quando for executar instruções desta natureza.
Tal solução prove a esta tecnologia significativo ganho no desempenho em relação à
tecnologia supracitada [14].

Virtualização no nível de sistema operacional: Este método de virtualização é o que
apresenta maior desempenho dentre todos. Pois as máquinas virtuais criadas são
instâncias do próprio sistema operacional hospedeiro, sendo denominados de servidor
virtual privado – VPS. Desta forma o compartilhamento de recursos é gerenciado pelo
próprio kernel do Linux, pois este tipo específico de virtualização não é suportado em
outros sistemas operacionais, pela necessidade de alteração do kernel tanto do sistema
hospedeiro quando das máquinas virtuais criadas a partir dele, e este prove também o
isolamento entre as diversas VPSs. No entanto, esta tecnologia apresenta diversos
problemas como: caso o kernel falhe todas as VPSs criadas terão problemas [14].
2.3.1. Xen Hipervisor
O Xen [66] é uma solução de código aberto para virtualização de infraestrutura que
provê uma camada de abstração entre o hardware e o sistema operacional e com isso, permite
a execução de vários sistemas operacionais em paralelo numa mesma máquina física. Ele possui
componentes que agendam a utilização dos recursos físicos pelas máquinas virtuais.
O hipervisor Xen possui suporte a para-virtualização [12], onde o sistema operacional
da máquina virtual tem a ilusão de estar executando diretamente sobre o hardware. Isso causa
uma melhoria considerável no desempenho das máquinas virtuais, se comparado com a
estratégia de virtualização total. Apesar de ser uma solução aberta, muitas plataformas
comerciais usam o Xen (ou versões adaptadas deste) para oferecer seus serviços, devido ao
36
desempenho proporcionado em comparação com as demais soluções abertas existentes [28],
como por exemplo, o Amazon EC2.
Um servidor necessita de três componentes para que o Xen seja executado, o próprio
hipervisor Xen, Domain 0 Guest e o Domain Guest (Figura 6).

Hipervisor Xen – este é executado diretamente sobre o hardware e se torna uma
interface para todas as requisições de I/O, CPU e disco dos sistemas operacionais
clientes.

Domain0 Guest – este componente é iniciado pelo hipervisor Xen a partir do boot do
sistema operacional, com exceção do Windows. O Dom0 possui privilégios exclusivos
para acessar o hipervisor Xen que não é atribuída a todos os clientes. Estes privilégios
permitem que ele administre todos os aspectos dos clientes, tais como iniciar, parar
pedidos de I/O.

Domain Guest – este denominado também como domínios privilegiados é iniciado e
controlado pelo Dom0 e operam o sistema de forma independente. Os clientes
necessitam de uma modificação no sistema operacional conhecido como paravirtualização ou sistemas operacionais não modificados precisam que o hardware a ser
virtualizado possua a tecnologia (Intel VT ou AMD-V) conhecida como hardware
virtual machine – HVM.
Figura 6 – Arquitetura Xen hipervisor.
2.3.2. KVM
O hipervisor KVM [1] foi inicialmente desenvolvido apenas para ser executado
utilizando o conceito de virtualização total, possuindo apenas aproximadamente 10.000 linhas
37
de código. No entanto hoje este monitor possui suporte a para-virtualização fazendo-se uso das
tecnologias Intel VT e AMD-V e está incluso na versão estável do kernel do Linux desde a
versão 2.6.20. O KVM não possui módulos específicos para o gerenciamento de recursos
alocados às máquinas virtuais criadas, ele utiliza o próprio kernel do Linux para efetuar essas
tarefas. Os sistemas operacionais utilizados para criar máquinas virtuais por meio do KVM não
necessitam de nenhuma alteração. Apesar de sua simplicidade o KVM presenta desempenho
aceitável para a execução de High Performance Computing – HPC [58].
2.4. Computação Autonômica
Sistemas de computação autonômica devem ter a capacidade de se gerenciarem e
adaptarem dinamicamente a mudanças de acordo com políticas e objetivos de negócios,
tornando possível que problemas frequentemente sejam identificados e corrigidos antes mesmo
de serem percebidos pelo pessoal de TI [30]. A essência da computação autonômica é o
autogerenciamento (self-management), que tem como objetivo livrar os administradores dos
detalhes da operação e manutenção dos sistemas e oferecer aos usuários máquinas que rodam
com alto desempenho e disponibilidade em rotina de 24/7. Essa característica justamente faz
com que essa abordagem se torne adequada ao gerenciamento de Smart Grid. O
autogerenciamento proporciona ao ambiente de nuvem a capacidade da realização da
elasticidade de forma automática.
As características de sistemas autonômicos se fazem necessários atualmente diante do
crescente aumento da complexidade dos sistemas. Tendo como base computação em nuvem
onde existe a presença de diversos tipos de sistemas trocando informações entre si sem que
exista a necessidade da intervenção humana para a sua manutenção. É imprescindível tornar
estas aplicações tolerantes não somente a falhas, mas também capazes de se recuperar
automaticamente proporcionando até certo nível independente de um especialista.
Existem quatro aspectos essenciais do autogerenciamento identificados como CHOP
[25][70]: autoconfiguração (self-configuration), autocura (self-healing), auto-otimização (selfoptimization) e autoproteção (self-protection) sendo cada um responsável por uma função em
específico e o conjunto destas prove o comportamento autonômico do sistema.

Autoconfiguração: significa que a configuração dos sistemas deve ser feita de maneira
automática, seguindo políticas de negócios de alto nível.
38

Autocura: diz respeito a sistemas que automaticamente detectam, diagnosticam e
recuperam dos problemas de software e hardware, em alguns casos isolando o
componente defeituoso.

Autoproteção: significa que os sistemas devem estar sempre à busca de possibilidades
para melhorar o seu desempenho e eficiência.

Auto-otimização: significa que os sistemas devem se defender automaticamente de
ataques ou múltiplas falhas em sequência.
39
Capítulo 3
Estudo de Caso: Gerenciador de Smart Grid
Este capítulo apresenta o Smart Grid Autonomic Management System – SGAMS, um
gerenciador que visa apresentar aspectos do ambiente de Smart Grid. Na seção 3.1 é apresenta
a visão geral do SGAMS e o modelo empregado para o seu desenvolvimento. Já na seção 3.2 é
detalhada a sua arquitetura e funcionamento.
3.1. Smart Grid
O conceito de Smart Grid se difere entre as diversas entidades reguladoras e fundações
no mundo. No entanto existe um consenso quando é afirmado que Smart Grid proporcionará
um aumento do percentual de fontes renováveis para a geração de energia, consequentemente
reduzindo assim a emissão de CO² na atmosfera [26]. Outro ponto em comum é na ideia de
reduzir o consumo de energia por meio da conscientização do cliente, devido às informações
que serão disponibilizadas para ele em tempo real do valor da energia naquele determinado
momento, tornado possível assim à escolha de um melhor momento para a utilização ou não de
equipamento elétrico. O gerenciamento eficiente da energia será possível devido à substituição
da infraestrutura existente atualmente, proporcionando assim a redução da taxa de perdas,
principalmente na transmissão da fonte de geração de energia até o consumidor final [19]. Caso
o consumidor possua em sua residência alguma fonte produtora de energia, painel fotovoltaico
ou gerador, este poderá vender a energia excedente produzida para a rede tornando-se assim
um produtor [62].
Figura 7 – Modelo conceitual de Smart Grid [8]
40
A arquitetura da infraestrutura de Smart Grid (Figura 7), tanto da rede de transmissão
de energia quanto de comunicação para fornecer os dados se difere da rede atual devido aos
objetivos de cada uma. A rede existente almeja apenas a disponibilização da energia elétrica
para o cliente, sem a existência do fornecimento de informações. Já em Smart Grid, prover
informação oriunda da rede elétrica é de suma importância, pois é por meio destas que o
consumidor poderá tomar decisões de qual o melhor momento para utilizar algum equipamento
elétrico. No entanto prover tais informações utilizando computação em nuvem apresenta
diversos desafios como[26]:

O custo-benefício para disponibilizar de forma incremental as novas funcionalidades
desenvolvidas para atender as necessidades sem a substituição de sistemas legados.

Prove a integração de sistemas internos com externos aos seus clientes/usuários de
forma segura.

Fornecer um framework para integrar recursos de terceiros e parceiros de forma fácil.

Permitir que novos recursos sejam implementados em paralelo às aplicações em
execução sem que haja impacto nas aplicações.

Utilizar SaaS com intuito de reduzir custo de desenvolvimento e implantação.
Para prover as informações para o consumidor final são utilizados os medidores
inteligentes (smart meter), estando esses presentes não somente na casa dos clientes, mas
também no meio de distribuição e transmissão. É por meio deles que será possível adicionar à
rede a capacidade de se auto proteger de determinadas falhas, e até mesmo se auto recuperar.
Através da troca de dados entre os diversos medidores a rede terá informações suficientes para
realizar a tomada de decisão até um determinado nível sem que seja necessária a intervenção
de um técnico especialista.
A implantação das redes de energia elétrica inteligentes está orçada na quantia de
bilhões, porém tal investimento apresenta viabilidade devido à economia nos segmentos
apresentados acima [8]. Além de viabilizar a ampla utilização dos Plug-in Hybrid Electric
Vehicles (PHEV), pois estes reduzem a dependência de combustíveis fosseis e ainda permite a
possibilidade deste venderem energia quando a tarifa for atrativa aos consumidores. No entanto
com a atual infraestrutura não seria possível suprir a necessidade de uma grande quantidade
desses veículos [26].
41
3.2. Visão Geral do Gerenciador de Smart Grid
Os desafios existentes em Tecnologias da Informação e Comunicação (TIC) na
implantação de Smart Grid levam à proposta de utilização da infraestrutura computacional da
nuvem. Os requisitos referentes à autonomia, configuração, tolerância à falha e gerenciamento
do sistema foram atendidos empregando os conceitos de computação autonômica. Com intuito
avaliar de a viabilidade de utilização da infraestrutura de computação em nuvem para atender
as necessidades do Smart Grid foi criado o Smart Grid Autonomic Management System –
SGAMS, sendo este executado em um ambiente de nuvem privada na UFABC - Figura 8.
Figura 8 – Modelo do SGAMS
Para obter a arquitetura mais próxima da realidade, o gerenciador possui três módulos,
responsáveis por tarefas distintas, mas que se completam para compor o ambiente de redes
inteligentes de energia elétrica. A disposição desses módulos e a interação entre eles podem ser
observadas na Figura 8. O módulo de geração simula a quantidade de carga elétrica a ser
produzida para a rede pelas concessionárias e pelos consumidores, sendo este último apenas
para aqueles que possuem meios para gerar tal carga. Além de determinar se um novo
consumidor possui ou não a capacidade de gerar eletricidade para a rede e se caso tenha, é
necessário determinar a quantidade e por quanto tempo.
O módulo de distribuição possui maior complexidade em comparação com o módulo de
geração, pois este é responsável por alocar e liberar automaticamente as máquinas virtuais
diante do aumento e redução do número de requisições dos consumidores. Tais requisições são
necessárias para informar os consumidores do valor atual da tarifa de energia.
O último módulo da aplicação é o de clientes, que tem como responsabilidade gerar
demanda para a oferta de energia. Este módulo efetua requisições constantes para o módulo de
distribuição com intuito de se manter atualizado do valor da tarifa.
42
3.3. Arquitetura
Com base no modelo proposto para o SGAMS foi desenvolvida a arquitetura do mesmo.
O módulo de geração foi implementado utilizando a infraestrutura da nuvem privada da
UFABC com a linguagem Java. Assim como o módulo anterior o módulo de distribuição foi
implantado na infraestrutura de nuvem da UFABC usando o controlador de nuvem
OpenNebula. Para prover os recursos autonômicos necessários para o módulo de distribuição,
como: elasticidade integrada com balanceamento de carga e o monitoramento tanto das
máquinas virtuais existentes quanto das aplicações sendo executadas nestas máquinas. Foram
utilizados recursos do próprio sistema operacional Debian, para evitar que o Tomcat [6],
servidor de aplicação que é responsável por disponibilizar os web services, fique indisponível.
Para tal tarefa foi implementado um script que verifica se o mesmo está executando. No entanto
para executar este script é utilizado cron job, este possui como funcionalidade que o
agendamento de tarefas seja para uma determinada data ou repetido a cada determinado
período. Por último será utilizado o PlanetLab (2.1.3.4) como um exemplo similar a nuvem
comunitária para o módulo cliente, onde cada máquina representa um conjunto de
consumidores de energia.
Figura 9 – Estrutura do XML de controle do módulo de distribuição e geração
Para prover a comunicação entre cada módulo será utilizado o conceito de Web Service
utilizando o protocolo SOAP [17]. Os dados transmitidos entre os módulos empregam a
estrutura de XML onde contém informações de controle (Figura 9). Tal XML possui o período
de duração da simulação, além dos dados necessário sobre as fontes utilizadas e o mínimo e
43
máximo de carga a ser gerada em cada uma delas. O módulo cliente por meio do Apache ODE
[5] realizou as requisições para a VM controle e esta tem como responsabilidade efetuar o
balanceamento de carga entre as diversas VMs existentes para a elasticidade.
Todo o ambiente proposto é virtualizado, desde os clientes no PlanetLab às máquinas
virtuais na nuvem privada da UFABC. Para tanto a Tabela 2 apresenta as configurações de
hardware das máquinas do ambiente utilizado nos experimentos.
Tabela 2 – Lista dos recursos computacionais das máquinas utilizadas no ambiente
Identificação
CPU
Memória
Disco Rígido
Quantidade
Servidor
Intel E1230 3.20
12 GB
1 TB
2
2 GB
10 GB
1
256 MB
2 GB
Depende do
GHz
Máquina virtual
1 core virtual de
controle
processamento
Máquina virtual
1 core virtual de
módulo
processamento
limiar para a
distribuição
elasticidade
Máquina virtual
1 core virtual de
1 GB
10 GB
1
módulo geração
processamento
Cliente
Varia de acordo
Varia de acordo
Varia de acordo
100
PlanetLab
com o host
com o host
com o host
44
Capítulo 4
Metodologia
Neste capítulo, é descrita a metodologia utilizada na pesquisa, visando a uma melhor
apresentação de seu desenvolvimento, tem suas seções subdivididas de maneira evolutiva,
assim, demarcando as fases do trabalho. Na seção 4.1 discutimos como foi realizada a coleta
nos módulos clientes e distribuição do SGAMS. Na seção 4.2 detalha-se o cenário utilizado nos
experimentos com e sem cloudburst. Na seção 4.3 são mostrados os fatores e níveis variados
nos experimentos. Na seção 4.4 são fixadas as métricas utilizadas para avaliação dos resultados
obtidos. E por fim, na seção 4.5 são citadas as ferramentas que auxiliaram o desenvolvimento
do projeto.
4.1. Processo de coleta nos módulos cliente e distribuição do
SGAMS
A identificação dos limiares para efetuar a elasticidade positiva e negativa é de suma
importância para o ambiente de Smart Grid. Tendo em vista que a escolha errada desses
parâmetros ocasionará a criação de uma nova VM antes do necessário, consequentemente o
custo com ambiente computacional irá aumentar. O contrário irá resultar em aumento no tempo
de resposta das requisições, sendo assim geraria queda na qualidade do serviço prestado.
Com intuito de definir os melhores parâmetros para serem utilizados na realização da
elasticidade, são coletados diversos dados em diferentes máquinas virtuais visando elucidar o
comportamento do tempo de resposta durante os experimentos. Entre os dados coletados os que
apresentam maior relevância são - Tabela 3: os tempos de respostas das requisições oriundas
dos clientes do PlanetLab, quantidade de requisições por segundo que chegam na máquina
virtual controle para serem redirecionados às VMs com o módulo de distribuição e a quantidade
de clientes do PlanetLab alocados para o experimento a cada 10 segundos, o intervalo de
alocação foi definido com o intuito de reduzir o tempo total do experimento sem comprometer
o comportamento de tempo de resposta das requisições. Pois, somente os tempos de respostas
das requisições não gerariam todas as informações necessárias para explicar o comportamento
dos tempos de respostas no decorrer do experimento.
45
Tabela 3 – Dados gerados para interpretação dos tempos de respostas
Log
Máquina Virtual
Descrição
Tempo de resposta da
Cliente PlanetLab
Tempo necessário para a
requisição
requisição SOAP ser
atendida pelo módulo
Distribuição
Quantidade de requisições
Balanceador de carga e
Quantidade de requisições
monitorador
simultâneas existentes a
cada segundo
Quantidade de VMs
Balanceador de carga e
Quantidade de VMs
monitor
alocadas na infraestrutura
da UFABC para
elasticidade
Número de clientes
Amazon WS
Número de nós do
PlanetLab alocados para
geração de carga
Utilização de CPU
Utilização de Memória
Máquinas virtuais para
Uso da CPU durante todo o
elasticidade
experimento
VMs para a elasticidade
Uso de memória durante
todo o experimento
Para garantir a integridade dos dados gerados no decorrer do experimento, se faz
necessária a sincronização de todas as máquinas virtuais utilizadas no experimento. Pois, cada
dado armazenado está vinculado a uma timestamp, número referente ao momento em que o
dado foi gerado, tendo em vista que devemos analisar as informações provenientes dos dados
estando no mesmo período de tempo. No entanto, sincronizar todos os clientes do PlanetLab
apresentou-se como uma tarefa muito dispendiosa. Tendo em vista que cada cliente pode
possuir uma distribuição do OpenSuse diferente, isso implica em repositórios de aplicativos
diferentes. E nem todos os repositórios possuíam o pacote necessário e suas dependências para
a sincronização dos clientes, no caso o ntp-date, e os que possuíam poderiam apresentar
problemas no momento da instalação, impossibilitando assim a sincronização dos clientes com
as VMs nos servidores da UFABC e com a máquina virtual na Amazon WS. Para contornar tal
problema foi implementado um aplicativo em Java que a partir das timestamp armazenadas de
cada um dos clientes do PlanetLab comparado com a timestamp na máquina virtual controle é
46
feito uma diferença de tempo, assim garantindo a integridade de todos os dados gerados nos
experimentos.
Para analisar o tempo de resposta de cada cliente do PlanetLab após cada experimento,
é feito o download de cada arquivo de log que contém o tempo de resposta vinculado ao
momento em que a requisição foi gerada. Desta forma ao final do download de todos os
arquivos de cada um dos clientes, os tempos de respostas juntamente com os demais logs
gerados tanto na própria máquina virtual controle, quanto com log oriundo da alocação dos
clientes gerado na VM criada na Amazon WS, são processados com intuito de serem
sincronizados. Em seguida todos os tempos de resposta são ordenados pelo momento em que
os dados foram gerados, sendo assim possível calcular a média, mediana e o percentil 90 do
acumulado de 10 segundos. Ao final do processamento de todos os logs torna-se possível
analisar as informações provenientes de cada experimento.
4.1.1. Cenário
Com o objetivo de identificar os melhores valores para os limiares positivos e negativos
para alocar e liberar, respectivamente, as VMs para disponibilizar o módulo de distribuição com
um tempo de resposta adequado. Foram realizados experimentos preliminares com intuito de
definir qual seria o tempo de resposta mínimo – TRm, além de determinar qual seria a
quantidade máxima de requisições simultâneas que uma VM criada para a elasticidade
suportaria antes que o tempo de resposta ultrapasse o limite de 10 segundos. Para responder tais
questões dois experimentos distintos foram executados.
O primeiro tinha como foco determinar o TRm, sendo assim foram alocados 100 clientes
do PlanetLab um após o outro sem que houvesse mais que um cliente gerando requisições
simultaneamente. Este experimento foi utilizado também para identificar quais clientes do
PlanetLab apresentavam tempos de resposta inferiores a 10 segundo. Pois, alguns clientes
demonstravam possuir recursos de rede insuficientes para a realização dos experimentos,
resultando assim em outliers, alguns como TRms acima de 400 segundos. O segundo
experimento tinha como foco determinar a quantidade máxima de requisições uma VM
conseguiria atender antes do TR superar o limite de 10 segundos. Para isso 100 clientes do
PlanetLab foram alocados a cada 10 segundos gerando requisições simultâneas.
47
4.1.1.2. Arquitetura utilizando a nuvem privada sem cloudburst
Como é observado na Figura 10, serão utilizados diferentes ambientes de nuvem para
executar o SGAMS. Com intuito de avaliar o uso do conceito de elasticidade na nuvem privada,
foi realizado um estudo de caso empregando o SGAMS na qual o módulo de distribuição está
implantado na infraestrutura da UFABC. Esta avaliação elucidará a relevância dos limiares e
uso da histerese para proporcionar estabilidade do tempo de resposta das requisições. Além de
apresentar a importância do uso da computação autonômica para prover autogerenciamento em
um ambiente de nuvem computacional. Tais resultados poderão ser utilizados para outras
aplicações que visam identificar métricas e parâmetros para a realização e liberação da
elasticidade.
Figura 10 – Arquitetura do SGAMS sem cloudburst
Com o intuito de descrever a: classificação, nível, tecnologia e a qual módulo estes
recursos estão alocados, a Tabela 4 foi criada com tais informações.
Tabela 4 – Estrutura da nuvem sem utilização da técnica de cloudburst
Classificação
Nível
Tecnologia
Módulo
Privada
IaaS
Xen Hipervisor
Geração
Privada
IaaS
OpenNebula
Distribuição
Comunitária
IaaS
PlanetLab
Cliente
48
4.1.2.
Arquitetura utilizando a nuvem privada com cloudburst
Para analisar o comportamento do tempo de resposta utilizando a técnica de cloudburst,
foi usado o SGAMS com a arquitetura que emprega o uso da nuvem pública da Amazon WS
quando os recursos da nuvem privada exauriram (Figura 11). Tal experimento proporciona
elucidar a viabilidade de uso de diferentes tipos de nuvem para compor um ambiente híbrido
para atender as requisições existentes em Smart Grid.
Nesta avaliação foram utilizados diferentes tipos de instâncias na Amazon a fim de identificar
qual apresenta melhor custo benefício. Tendo em vista que o uso de recursos da nuvem pública
reflete no aumento do investimento na infraestrutura computacional para atender as requisições.
Figura 11 – Arquitetura do SGAMS com cloudburst
Para descrever o ambiente apresentado em Figura 11 é observado Tabela 5, onde são
detalhadas quais classificações de nuvem, nível de utilização, tecnologia empregada e a qual
módulo está vinculado o ambiente usado para implantar o SGAMS.
Tabela 5 – Estrutura da nuvem com utilização da técnica de cloudburst
Classificação
Nível
Tecnologia
Módulo
Privada
IaaS
Xen Hipervisor
Geração
Privada
IaaS
OpenNebula
Distribuição
Comunitária
IaaS
PlanetLab
Cliente
Pública
IaaS
Amazon WS
Distribuição
49
4.2. Fatores e níveis
O objetivo de determinar os melhores limiares para efetuar a elasticidade é o de reduzir
o custo com a infraestrutura de nuvem, seja ela pública ou privada, sem comprometer a
qualidade de experiência do usuário com o serviço provido. Para tanto foram realizados
experimentos que consistiam em alocar 100 clientes configurados no PlanetLab para gerar
requisições seguindo a distribuição de Poisson, esta distribuição define o intervalo entre as
chegadas das requisições, para uma máquina virtual com o Apache, doravante referenciada
como VM controle. Está máquina virtual controle situada na nuvem privada da UFABC tem
como responsabilidade o redirecionamento das requisições para as VMs com o módulo de
distribuição, na nuvem privada da UFABC ou na nuvem pública da Amazon WS, e efetuar o
monitoramento dessas VMs. Tal função se faz necessária para identificar o momento que
deverá ser realizada à elasticidade positiva ou negativa.
O conceito de histerese empregado nos experimentos foi o de fazer com que os limiares
tanto positivo quanto negativo fossem superados ao menos duas vezes seguidas, para que fosse
realizada a elasticidade. Quando o valor para histerese for zero, os limiares só precisavam ser
superados uma vez e após isso já era efetuada a elasticidade. Tal conceito foi utilizado como
um fator devido à realização desnecessária da elasticidade para atender a um pico de consumo.
Sendo assim após o pico seria efetuada a elasticidade negativa, no entanto o custo de se fazer a
elasticidade pode ser muito alto para atender a apenas um pico. Neste cenário a histerese se
enquadra para evitar tal fato.
4.2.1. Limiares utilizados nos experimentos sem cloudburst
Para os experimentos que utilizaram apenas a nuvem privada da UFABC foram
definidos os limiares positivo e negativos para efetuar a elasticidade (Tabela 6), além do
emprego de histerese. Tais limiares foram escolhidos com o intuito de apresentar o impacto de
sua variação para a realização da elasticidade.
Tabela 6 – Lista de fatores e níveis utilizados nos experimentos sem cloudburst
Fatores
Níveis
Limiar positivo
250
300
350
Limiar negativo
100
125
150
Histerese
Não
Sim
50
Outros experimentos adicionais foram realizados a fim de elucidar questões que
surgiram após análise dos resultados provenientes dos limiares da (Tabela 6). Os limiares para
elasticidade positiva e negativa usando a quantidade de requisições para os experimentos
adicionais estão Tabela 7. Estes não foram combinados com os demais limiares, sendo assim
são experimentos únicos que visam apresentar diferenças entre os demais resultados obtidos.
Tabela 7 – Lista de fatores e níveis dos experimentos adicionais sem cloudburst
Fatores
Níveis
Limiar positivo
400
600
Limiar negativo
125
150
4.2.2. Limiares utilizados nos experimentos com cloudburst
Para os experimentos que empregavam a técnica de cloudburst foi usado o limiar
positivo e negativo de 350 e 150 respectivamente, pois estes limiares apresentaram resultados
satisfatórios para a elasticidade utilizando apenas a nuvem privada, sendo assim ao
empregarmos estes mesmos limiares para os experimentos com cloudburst as variações nos
tempos de respostas seriam causadas apenas pelo tipo de VM escolhida na Amazon WS. No
entanto a variação se deu no tipo de instância na Amazon WS, foram escolhidos três tipos
distintos de máquinas virtuais: large, medium e small, os recursos computacionais de cada um
dos tipos supracitados podem ser visto na Tabela 1.
4.3. Métricas
Para análise do comportamento dos tempos de resposta dos clientes que geram carga a
partir do PlanetLab, foram definidas métricas a serem utilizadas.

Tempo de resposta: intervalo de tempo entre o cliente emitir uma requisição e receber
a resposta do servidor. São calculadas três estatísticas (média, mediana e percentil 90)
de todos os tempos de resposta a cada intervalo de 10 segundos.

Recursos computacionais: comprometimento de recursos computacionais pelo provedor
de nuvem, medido através do número de máquinas virtuais alocadas para o usuário.

Carga de trabalho: número de requisições simultâneas existente na VM controladora.

Nós do PlanetLab: número de nós do PlanetLab alocados para gerar a carga de trabalho,
onde cada nó no PlanetLab é usado para modelar o comportamento de um determinado
51
número de clientes (residências) do Smart Grid (o valor exato depende de cada
ambiente). Por exemplo, cada nó envia uma requisição ao servidor a cada 3 segundos.
Se considerarmos um ambiente de Smart Grid onde cada cliente envia uma requisição
a cada 2 minutos, então temos uma relação de 1:40, ou seja, um nó PlanetLab representa
40 clientes Smart Grid.

Utilização de CPU: média de utilização de CPU de todas as máquinas virtuais alocadas,
calculada a cada 30 segundos.

Utilização da memória: média de utilização de memória de todas as máquinas virtuais
alocadas, calculada a cada 30 segundos.
Tais métricas juntas viabilizam uma análise minuciosa do comportamento dos TRs no
decorrer do experimento. O cálculo da média, mediana e percentil 90, proporciona a
identificação de outliers. Sendo assim ocorrendo alguma instabilidade nos clientes alocados
para a realização do experimento, esta será facilmente identificada. A partir da quantidade de
clientes juntamente com a quantidade de requisições simultâneas existentes para a geração de
carga podemos comprovar a necessidade ou não da realização da elasticidade. O número de
VMs criadas para a elasticidade é o reflexo das duas métricas citadas anteriormente.
A métrica escolhida para efetuar a elasticidade, positiva e negativa, foi a quantidade de
requisições simultâneas. Sendo esta dividida pelo número de máquinas virtuais existentes para
elasticidade, desta forma obtemos a quantidade de requisições por VM. Tal métrica foi
escolhida diante da comparação com a utilização de CPU e memória. O uso de CPU mostrouse ser uma métrica muito sensível a menor oscilação na quantidade de requisições. Já utilização
de memória apresentou diversos problemas decorrentes da quantidade limitada de memória
alocada a cada VM para elasticidade, exatamente de 256 MB. Outra motivação para ser
utilizada a quantidade de requisições como parâmetro para a elasticidade é que por essa ser uma
métrica mais direta que as supracitadas apresenta maior precisão para esta finalidade.
4.4. Ferramentas utilizadas
Para a realização dos experimentos foram utilizadas diversas ferramentas com
finalidades distintas, para tanto pode ser observado na Tabela 8.
Tabela 8 – Lista de ferramentas com funcionalidades e emprego
Nome
Funcionalidade
Localização
52
Xen
OpenNebula
Monitor
Scripts
Java
Hipervisor para o
gerenciamento das máquinas
virtuais
Controlador de nuvem
utilizado para prover o
gerenciamento de alto nível
das VMs
Aplicativo escrito em Java
para executar scripts de
monitoramento
Diversos scripts foram
implementados utilizando a
linguagem Shell Script para
efetuar desde a verificação
da necessidade de realizar
elasticidade à alocação dos
clientes do PlanetLab para a
geração de carga
Desenvolvimento do
ambiente de Smart Grid
Nuvem privada da UFABC
Nuvem privada da UFABC
Nuvem privada da UFABC
Nuvem privada da UFABC,
nuvem pública da Amazon
WS, clientes do PlanetLab
Nuvem privada da UFABC,
Amazon WS
4.5. Experimentos
Para a realização dos experimentos foi definido um intervalo fixo de 60 segundos entre
o início de cada ciclo de monitoramento. Cada experimento apresenta um tempo médio de
aproximadamente 45 minutos, no entanto são necessários mais 15 minutos para fazer download
dos logs em todos os nós do PlanetLab, ao todo foram executadas 230 horas de experimentos.
Diversos problemas ocorreram ao utilizar a nuvem comunitária do PlanetLab, o principal
motivo para esses problemas é a heterogeneidade dos servidores que compõem esta nuvem.
Cada nó possui como distribuição base o OpenSuse, no entanto não é possível dizer qual versão
da distribuição instada em cada nó até que seja criada uma máquina virtual e a partir desta seja
verificada a versão usada. A variação das versões do sistema operacional resulta na mudança
dos repositórios a serem utilizados para a instalação dos aplicativos. Para cada programa que
fosse necessário instalar nos nós para a realização dos experimentos foi preciso a transferência
do binário deste aplicativo e a instalação a partir do binário.
Outro problema existente no PlanetLab é a variação dos recursos computacionais de
cada nó na nuvem. Ao realizar experimentos preliminares para determinar o TRm foi possível
constatar que 10% dos nós criados não possuíam recursos suficientes para executar os
experimentos. Estes outliers foram responsáveis por prejudicar algumas amostras resultando
em mais tempo de execução dos experimentos.
53
Capítulo 5
Resultados
Os resultados a seguir são provenientes dos experimentos detalhados na seção anterior.
Foram escolhidos alguns limiares dentre os utilizados nos experimentos, para mostrar o impacto
dos mesmos no tempo de resposta das requisições.
Todos os resultados são apresentados em oito grupos de gráficos distintos, alguns visam
apresentar os resultados de uma única amostra de experimento e outros a média das amostras.
Os gráficos do tipo (a) de uma única amostra representa o comportamento dos tempos de
respostas em segundos durante todo o experimento, já (b) representam a carga de trabalho
gerada pelos nós no PlanetLab. Em (c) é apresentado o número de máquinas virtuais existentes
para a elasticidade, no (d) é mostrado o número de nós no PlanetLab alocados para gerar as
requisições. Tanto em (e) quanto em (f) são mostradas as médias da porcentagem de utilização
de memória e CPU, respectivamente, das máquinas virtuais para elasticidade. Esses gráficos
são específicos para representar apenas uma iteração de cada experimento. No entanto, foram
realizadas dez iterações com intuito de verificar a sua relevância, pois uma única amostra não
é representativa. Para tanto os últimos dois gráficos são das médias dos tempos de respostas e
dos recursos computacionais alocados para elasticidade. Ambos os gráficos utilizam o intervalo
de confiança de 99%. Os gráficos de médias do tipo (a) representam a média dos tempos de
respostas. Enquanto em (b) a média do número de máquinas virtuais criadas nos experimentos.
Já em (c) é observada a frequência dos tempos de respostas de todas as amostras para o
determinado experimento.
5.
Experimentos sem histerese
Para mostrar o menor tempo de resposta possível foram escolhidos os limiares com
menor valor – ver Tabela 6, pois com estes a elasticidade será realizada antes, garantido assim
mais estabilidade durante todo o experimento. Para comprovar esta afirmação pode ser
observada na Figura 12(a), onde é constatado que durante todo o experimento a média dos TRs
não ultrapassou 3 segundos mesmo quando a quantidade de requisições chegou perto das 4.000
requisições simultâneas (Figura 12 (b)). Foram necessárias ao todo 12 máquinas virtuais na
nuvem privada da UFABC (Figura 12(c)) para manter os tempos de resposta dentro do limite
aceitável de 10 segundos.
54
Como esperado a quantidade de requisições Figura 12 (b) seguiu o mesmo padrão de
alocação dos nós do PlanetLab Figura 12(d). A média de utilização de memória Figura 12(e)
permanece entre 60% e 70% durante grande parte do experimento. Este comportamento ocorre
devido a diversos fatores, dentre eles podemos citar: para disponibilizar o serviço é utilizado o
Tomcat, um servidor web Java mais precisamente um container de servlets. Este container aloca
a memória necessária para atender as requisições, no entanto mesmo após o termino da
requisição este não libera toda a memória alocada. Sendo assim a única forma de saber
precisamente quanto de memória está realmente ocupada seria necessário o restart do Tomcat.
Outro fator impactante é a quantidade de memória alocada as máquinas virtuais exatamente
256 MB. Tal valor foi definido propositalmente com o intuito de ser necessária a realização da
elasticidade para manter os tempos de resposta dentro do limite estabelecido. Já o uso de CPU
Figura 12(f) varia durante todo o experimento, mostrando assim não ser um bom parâmento
para a realização da elasticidade. Pois a ocorrência de qualquer pico de utilização pode gerar a
criação de uma nova VM sem a sua real necessidade, a utilização de histerese neste caso pode
7
Média
6
Mediana
Percentil 90
Segundos
5
4
3
2
Número de requisições
ser benéfica.
1
0
Minutos
Minutos
(a) Tempo de Resposta
100
12
75
Número de nós
Número de máquinas virtuais
15
(b) Carga de trabalho
9
6
50
25
3
0
0
Minutos
Minutos
55
(c) Recursos Computacionais
(d) Número de nós do PlanetLab
100
90
80
70
60
50
40
30
20
10
0
(%)
(%)
100
90
80
70
60
50
40
30
20
10
0
Minutos
Minutos
(e) Utilização de Memória
(f) Utilização de CPU
Figura 12 – Experimento com limiares positivo e negativo 250 e 100
respectivamente e sem histerese.
Com intuito de elucidar os limiares mais adequados para obter os tempos de respostas
dentro do limite de 10 segundos, mas sem a necessidade de criar tantas máquinas virtuais como
no experimento anterior, foi definida a utilização dos limiares positivos e negativos 400 e 125
respectivamente. Observando a Figura 13(a) fica evidente que com esses limiares existe
instabilidade, porém somente no início do experimento. Tal comportamento é consequência no
atraso para realizar a elasticidade, como no início só existe apenas uma máquina virtual para
disponibilizar o serviço, esta fica sobrecarregada de requisições. Porém à medida que outras
máquinas virtuais são criadas o atraso na criação de mais uma VM não apresenta reflexo nos
tempos de resposta. Com esses limiares a média dos TRs assim como no experimento anterior
ficou abaixo dos 3 segundos.
O número de requisições se aproximou também das 4.000 requisições simultâneas
(Figura 13(b)). No entanto o número de VMs para a elasticidade foi menor alcançando 10
máquinas simultâneas (Figura 13(c)). Tal resultado mostra que caso uma instabilidade inicial
for admissível para o ambiente é mais viável a utilização desses limiares aos do primeiro
experimento. A alocação dos nós do PlanetLab (Figura 13(d)) se dá de forma linear, no entanto
para liberar o nó da geração da carga existe um atraso. Este é devido à necessidade de matar o
processo do script responsável pela geração da carga. Alguns nós podem requerer mais tempo
que outros clientes ocasionando assim a diferença da duração de cada experimento.
A instabilidade existente no início do gráfico do tempo de resposta é observada também
na média de utilização de memória (Figura 13(e)), após a média se estabilizar os TRs seguem
56
o mesmo comportamento. No entanto a média de utilização de CPU Figura 13(f) não seguiu o
mesmo desempenho, mostrando ser bastante sensível consequentemente instável.
70
Média
60
Segundos
Percentil 90
40
30
20
Número de requisições
Mediana
50
10
0
Minutos
Minutos
(a) Tempo de Resposta
(b) Carga de trabalho
100
8
Número de nós
Número de máquinas virtuais
10
6
4
75
50
25
2
0
0
Minutos
Minutos
(c) Recursos Computacionais
(d) Número de nós do PlanetLab
100
100
90
90
80
80
70
60
60
(%)
(%)
70
50
50
40
40
30
30
20
20
10
10
0
0
Minutos
Minutos
(e) Utilização de Memória
(f) Utilização de CPU
Figura 13 – Experimento com limiares positivo e negativo 400 e 125
respectivamente e sem histerese.
57
Os últimos limiares escolhidos para mostrar instabilidade durante a maior parte do
experimento foram 600 e 150 para elasticidade positiva e negativa respectivamente. Ao utilizar
esses limiares os tempos de resposta ficaram acima dos trinta segundos (Figura 14(a)). No
entanto, próximo aos 30 minutos de experimento o tempo de resposta cai para um nível
aceitável, abaixo de 10 segundos. Tal fato acorre devido ao número de VMs já existentes para
atender as requisições e a quantidade de requisições Figura 14(b) neste momento também já
estava reduzindo.
Observa-se que ao final do experimento foram criadas apenas nove máquinas virtuais
Figura 14(c) para atender todas as requisições, fato este que comprometeu o tempo de resposta
das requisições durante a alocação dos nós do PlanetLab Figura 14(d). Tais clientes foram
alocados sem a ocorrência de atrasos, porém a liberação não teve o mesmo êxito, pois é possível
observar ao menos um ponto onde o cliente apresentou atraso para a sua liberação. Este fato
reflete diretamente no tempo de duração do experimento, comparando com os dois antecessores
este foi o que apresentou maior duração cerca de 45 minutos. A instabilidade do experimento
não ficou apenas nos tempos de respostas, este comportamento também pode ser visto nos
gráficos de utilização de CPU Figura 14(f) e memória Figura 14(e). Sendo este último
120
Média
Mediana
Percentil 90
100
Segundos
80
60
40
Número de requisições
interessante devido à estabilidade que o mesmo mostrou nos experimentos anteriores.
20
0
Minutos
Minutos
(a) Tempo de Resposta
(b) Carga de trabalho
58
100
9
75
7
Número de nós
Número de máquinas virtuais
8
6
5
4
3
50
25
2
1
0
0
Minutos
Minutos
(c) Recursos Computacionais
(d) Número de nós do PlanetLab
100
100
90
80
70
60
50
40
30
20
10
0
90
80
70
(%)
(%)
60
50
40
30
20
10
0
Minutos
Minutos
(e) Utilização de Memória
(f) Utilização de CPU
Figura 14 – Experimento com limiares positivo e negativo 600 e 150
respectivamente e sem histerese.
Como pode ser observada na Figura 15(a) a instabilidade é presente no terceiro e último
experimento. Sendo com o limiar de 600 para elasticidade positiva é explicado com a oscilação
dos tempos de resposta no início do experimento que chegam a 100 segundos e ao final do
experimento não passam de 10 segundos. Já para o gráfico de tempos de respostas Figura 15(b),
apesar de o primeiro experimento apresentar o tempo de respostas mais baixo, foi o que
demonstrou maior oscilação no número de máquinas virtuais criadas para a elasticidade
refletindo no aumento do intervalo de confiança. Os experimentos com limiares positivos iguais
apresentam comportamento parecido em se tratando de alocação de recursos computacionais.
Ao observar Figura 15(c) é possível constatar que mais de 90% dos tempos de resposta de todas
as amostras dos experimentos utilizando a nuvem privada da UFABC foram menores que 4
segundos. Este resultado implica dizer que mesmo utilizando limiares ruins esta abordagem
apresentou-se ser viável para ser utilizada.
59
14
Número de máquinas virtuais
25
12
20
Segundos
10
15
10
5
0
8
6
4
2
0
Experimentos
Experimentos
Histograma e CDF
(a) Média dos tempos de resposta
(b) Média dos recursos computacionais
90
1
80
0,9
70
0,8
0,7
60
0,6
50
0,5
40
0,4
30
0,3
20
0,2
10
0,1
0
0
2
4
7
9
12
14
17
20
22
25 Mais
Tempos de Resposta
(c) Histograma e CDF dos tempos de resposta
Figura 15 – Médias dos tempos de resposta e do número de máquinas virtuais existentes para os
experimentos sem histerese.
5.2. Experimentos com histerese
Os experimentos com histerese visavam controlar a criação e liberação de máquinas
virtuais diante de um pico ou vale de requisições. No entanto, como pode ser observada na
Figura 16(a), tal técnica não demonstrou o resultado esperado. A adição de um ciclo de
monitoramento no atraso na criação da VM resultou em instabilidade do tempo de resposta das
requisições. O número de requisições (Figura 16(b)) geradas neste experimento foi próximo
dos experimentos anteriores, logo este não foi o motivo da oscilação nos tempos de resposta. O
número de máquinas virtuais (Figura 16(c)) criadas para a elasticidade foi idêntica ao
experimento com limiares 400 e 125, positivo e negativo respectivamente. Porém no
experimento anterior os resultados foram satisfatórios. A utilização de memória (Figura 16(e))
apresentou maior oscilação no mesmo momento em que os tempos de resposta tiveram o
mesmo comportamento. Já a utilização de CPU, Figura 16(f), esteve próxima ao máximo até
60
os 20 primeiros minutos do experimento, momento este em que os TRs estavam acima do limite
de 10 segundos.
120
Média
100
Segundos
Percentil 90
60
40
20
Número de requisições
Mediana
80
0
Minutos
Minutos
(a) Tempo de Resposta
(b) Carga de trabalho
100
8
75
Número de nós
Número de máquinas virtuais
10
6
4
50
25
2
0
0
Minutos
Minutos
(c) Recursos Computacionais
(d) Número de nós do PlanetLab
100
100
90
90
80
80
70
(%)
(%)
70
60
50
60
50
40
40
30
30
20
20
10
10
0
0
Minutos
Minutos
(e) Utilização de Memória
(f) Utilização de CPU
Figura 16 – Experimento com limiares positivo e negativo 300, 125
respectivamente e com histerese.
61
Este experimento tem como objetivo verificar a diferença que a histerese causa no tempo
de resposta da requisição. Comparando a Figura 17(a) com a Figura 16(a) podemos observar
que o primeiro apresenta instabilidade apenas no começo. Já no segundo os tempos de resposta
ficam acima dos 10 segundos em grande parte do experimento. Com esses limiares a utilização
de histerese afetou negativamente os TRs em comparação com o mesmo experimento sem a
histerese. O número de requisições Figura 17(b) foi ligeiramente menor devido à aleatoriedade
entre o intervalo das requisições. No entanto esta métrica não foi fator determinante para a
diferença entre os tempos de resposta durante todo o experimento. O número de máquinas
virtuais Figura 17(c) é notoriamente menor, tendo em vista que três VMs a menos para fazer a
elasticidade irá causar sobrecarga no ambiente.
A alocação dos nós do PlanetLab Figura 17(d) não influenciou nos resultados, pois
foram utilizados 100 clientes em todos os experimentos. Mesmo existindo alguns clientes que
vieram a causar problemas na geração de carga, estes não poderiam prejudicar severamente os
tempos de resposta. Ao comparar os gráficos de utilização de memória Figura 17(e) com o do
experimento anterior, podemos identificar um padrão de estabilidade no experimento sem
histerese. No entanto a CPU Figura 17(f) oscilou em ambos os experimentos, mas na iteração
com histerese a variação de utilização foi notoriamente maior.
70
Mediana
Segundos
50
Percentil 90
40
30
20
Número de requisições
Média
60
10
0
Minutos
(a) Tempo de Resposta
Minutos
(b) Carga de trabalho
62
100
Número de máquinas virtuais
12
10
Número de nós
75
8
50
6
4
25
2
0
0
Minutos
Minutos
(c) Recursos Computacionais
100
90
80
70
60
50
40
30
20
10
0
(d) Número de clientes
(%)
(%)
100
90
80
70
60
50
40
30
20
10
0
Minutos
Minutos
(e) Utilização de Memória
(f) Utilização de CPU
Figura 17 – Experimento com limiares positivo e negativo 300, 125
respectivamente e sem histerese.
Como pode ser observado na Figura 18(a), todos os experimentos independentemente
dos limiares diferentes com histerese apresentaram tempos de resposta insatisfatórios. Outro
fator impactante é a oscilação no intervalo de confiança, tal fato comprova a instabilidade que
a histerese adiciona ao ambiente analisado. A quantidade de máquinas virtuais criadas Figura
18(b) é próxima para todos os limiares, ao contrário do comportamento dos experimentos sem
histerese Figura 15(a). Ao analisarmos Figura 18(c) fica evidente que menos de 1% dos tempos
de resposta utilizando histerese se aproxima do limite de 10 segundos. Desta forma é
inviabilizado o uso da técnica de histerese para os limiares utilizados nestes experimentos.
63
45
12
40
10
Número de máquinas virtuais
35
30
Segundos
25
20
15
10
5
0
(a) Média dos tempos de resposta
8
6
4
2
0
(b) Média dos recursos computacionais
35
1
0,9
30
Histograma e CDF
0,8
25
0,7
0,6
20
0,5
15
0,4
0,3
10
0,2
5
0,1
0
0
11
16
21
26
30
35
40
45
50 Mais
Tempo de Resposta
(c) Histograma e CDF dos tempos de resposta
Figura 18 – Média do tempo de resposta e número de máquinas virtuais com histerese.
5.3. Experimentos com Cloudburst
Os experimentos com cloudburst visam elucidar não somente o comportamento do
tempo de resposta utilizando um ambiente de nuvem híbrida, mas como também a influência
que os diferentes tipos de instâncias provocam no comportamento dos TRs. Para tanto, parte
das máquinas virtuais criadas para elasticidade utilizou a infraestrutura da nuvem privada da
UFABC e após o limite de oito VMs passaram a ser criadas na nuvem pública da Amazon WS
utilizando o serviço EC2. Como já foi descrito em Tabela 1 variam os recursos computacionais
de cada tipo de instância, sendo assim escolhemos as que seriam relevantes para serem
analisadas.
Como pode ser observado na Figura 19(a) fica evidente que os tempos de respostas
ficam instáveis no momento em que as novas máquinas virtuais são criadas na Amazon. Tal
64
comportamento permanece até o momento em que estas VMs são enfim liberadas. Sendo assim
podemos afirmar que realizar cloudburst com instâncias do tipo small não será satisfatório, pois
este irá causar instabilidade para atender as requisições. Tanto o número de requisições (Figura
19(b)) como a alocação e liberação dos nós do PlanetLab Figura 19(d) não foram responsáveis
para instabilidade existente no experimento, tendo em vista que ambos foram similares aos
experimentos já apresentados.
Ao observamos a Figura 19(c) e compararmos com a Figura 17(d) podemos afirmar que
o número de máquinas virtuais criadas para elasticidade também não foi o motivo pela qual
gerou a instabilidade. Desta forma é perceptível a razão pela qual ocorreu tal oscilação no tempo
de resposta, os recursos computacionais das instâncias da Amazon WS não foram suficientes
para suportar a carga gerada. Analisando os resultados de utilização de memória Figura 19(e) é
visível o momento em que as VMs começam a ficar sobrecarregadas, pois esta situação
encontra-se refletida principalmente entre os primeiros 20 e 30 minutos de experimento. No
caso da CPU (Figura 19(f)) a instabilidade está presente em todos os momentos, mostrando que
esta métrica é muito sensível a picos de utilização.
60
Média
Mediana
Percentil 90
Número de requisições
70
Segundos
50
40
30
20
10
0
Minutos
Minutos
(a) Tempo de Resposta
(b) Carga de trabalho
Amazon WS
Número de máquinas virtuais
12
100
Nuvem Privada
10
Número de nós
75
8
50
6
4
25
2
0
0
Minutos
Minutos
65
(c) Recursos Computacionais
(d) Número de nós do PlanetLab
100
90
90
80
80
70
70
60
60
(%)
(%)
100
50
50
40
40
30
30
20
20
10
10
0
0
Minutos
Minutos
(e) Utilização de Memória
(f) Utilização de CPU
Figura 19 – Experimento com limiares positivo e negativo 350, 150 respectivamente e com
cloudburst utilizando VMs do tipo small.
Neste experimento podemos observar uma notável diferença no comportamento dos
tempos de resposta da Figura 20(a) em comparação com a Figura 19(b). Fica evidente que o
incremento de recursos computacionais para cloudburst reflete diretamente na média dos TRs.
Utilizando instâncias do tipo medium ao invés de small o custo com a infraestrutura de nuvem
para disponibilizar os serviços dobram de valor, no entanto o resultado é notoriamente melhor.
Durante todo o tempo de duração do experimento os tempos de respostas permaneceram
estáveis e na média não ultrapassaram o tempo de 4 segundos independentemente da quantidade
de requisições existentes Figura 20(b).
Ao observar Figura 20(c) em comparação com Figura 19(c) fica evidente que a grande
diferença entre os recursos computacionais de cada um dos tipos de instâncias influenciaram
no tempo de resposta. Pois no experimento anterior foram criadas três VMs na Amazon WS e
mesmo assim houve grande oscilação na nuvem pública. Enquanto que no experimento
utilizando instâncias do tipo medium foram criadas apenas duas VMs e os tempos de resposta
permaneceram dentro do limite estabelecido como ideal. Os resultados de utilização tanto de
CPU Figura 20(f) quanto de memória Figura 20(e) ficaram mais estáveis com este tipo de
instância. Sendo este último reduzindo a carga em aproximadamente 20% quando novas
máquinas virtuais começaram a ser criadas na Amazon WS. Este comportamento ocorreu pela
quantidade de memória alocada às novas VMs em comparação com as que foram criadas na
nuvem privada, na nuvem pública as máquinas virtuais possuíam 3,75 GB (Tabela 1) enquanto
que na infraestrutura da UFABC apenas 256 MB.
66
Média
Mediana
Percentil 90
Número de requisições
6
Segundos
4
2
0
Minutos
Minutos
(a) Tempo de Resposta
Amazon AWS
Nuvem Privada
12
100
75
10
Número de nós
Número de máquinas virtuais
(b) Carga de trabalho
8
6
4
50
25
2
0
0
Minutos
Minutos
(c) Recursos Computacionais
(d) Número de nós do PlanetLab
100
90
90
80
80
70
70
60
60
(%)
(%)
100
50
50
40
40
30
30
20
20
10
10
0
0
Minutos
(e) Utilização de Memória
Minutos
(f) Utilização de CPU
Figura 20 – Experimento com limiares positivo e negativo 350, 150 respectivamente e com
cloudburst utilizando VMs do tipo medium.
Ao observarmos a Figura 21(a) em relação à Figura 20(a) fica evidente que o ganho com
desempenho dos tempos de resposta é pequeno, em torno de 0,047 segundos na média. Tal
67
ganho não justifica dobrar o investimento em recursos computacionais de nuvem pública, fica
claro que qualquer instância mais robusta que a medium apresentará um desempenho melhor.
No entanto, algo que deve ser levado em consideração é a relação custo benefício, no caso,
investimento em recurso computacional e diminuição/estabilidade dos tempos de resposta.
Verificando o número de máquinas virtuais criadas para a elasticidade Figura 21(c) é
possível constatar que não houve oscilação em relação ao experimento anterior. Assim como
não houve uma brusca mudança no número de requisições geradas para o experimento Figura
21(b). Alguns nós no PlanetLab apresentaram a necessidade de mais tempo para liberar a
geração de carga (Figura 21(d)), porém não influenciou no resultado. É possível identificar no
resultado da média de memória Figura 21(e) em que momento começa e termina o cloudburst,
o impacto do mesmo no experimento é notório. O mesmo comportamento ocorre com a CPU
(Figura 21(f)), no entanto a estabilidade da memória não se repete nesta métrica.
Média
Mediana
Percentil 90
Segundos
8
6
4
2
Número de requisição
10
0
Minutos
Minutos
(a) Tempo de Resposta
Amazon AWS
Nuvem Privada
12
Número de máquinas virtuais
(b) Carga de trabalho
100
Número de nós
10
8
6
4
75
50
25
2
0
0
Minutos
(c) Recursos Computacionais
Minutos
(d) Número de nós do PlanetLab
68
100
90
90
80
80
70
70
60
60
(%)
(%)
100
50
50
40
40
30
30
20
20
10
10
0
0
Minutos
(e) Utilização de Memória
Minutos
(f) Utilização de CPU
Figura 21 – Experimento com limiares positivo e negativo 350, 150 respectivamente e com
cloudburst utilizando VMs do tipo large.
Com o intuito de verificar a diferença entre utilizar ou não a técnica de cloudburst para
suprir a necessidade de recursos computacionais oriundas dos picos de consumo, foi realizado
um experimento com os mesmos limiares, porém sem cloudburst usando somente a
infraestrutura da nuvem privada da UFABC. Observando Figura 22(a) podemos constatar que
o resultado obtido neste experimento é similar aos atingidos quando utilizamos a nuvem pública
com as máquinas virtuais do tipo medium e large. Sendo assim podemos afirmar que a
infraestrutura da Amazon WS pode fornecer um ambiente estável, contudo para que tal objetivo
seja alcançado é necessário investir em máquinas virtuais com maior poder computacional.
Analisando a métrica de número de VMs (Figura 22(b)), podemos observar que foram
criadas menos máquinas virtuais que nos experimentos anteriores. Esse fato ocorre devido à
quantidade de requisições (Figura 22(c)) neste experimento ser ligeiramente menor que os
experimentos anteriores, em torno de 200 requisições a menos no ápice. A utilização de
memória (Figura 22(e)) apresenta instabilidade no início do experimento devido a pouca
quantidade de VMs para a elasticidade. Quando a carga começa a ser distribuída entre as
diversas máquinas virtuais esta métrica tende a se estabilizar até o final do experimento. Assim
como a utilização de memória a CPU Figura 22(f) inicia com alta porcentagem de uso e
reduzindo à medida que novas VMs são criadas. No entanto, ao final do experimento volta a
existir instabilidade devido à sensibilidade desta métrica.
69
Média
Mediana
Percentil 90
Número de requisições
9
Segundos
6
3
0
Minutos
Minutos
(a) Tempo de Resposta
100
12
75
9
Número de nós
Número de máquinas virtuais
(b) Carga de trabalho
6
50
3
25
0
0
Minutos
Minutos
(c) Recursos Computacionais
(d) Número de nós do PlanetLab
100
100
90
80
70
60
50
40
30
20
10
0
90
80
70
(%)
(%)
60
50
40
30
20
10
0
Minutos
(e) Utilização de Memória
Minutos
(f) Utilização de CPU
Figura 22 – Experimento com limiares positivo e negativo 350, 150 respectivamente e sem
cloudburst.
Como pode ser observado na Figura 23(a) comparando o comportamento do tempo de
resposta em um ambiente controlado da infraestrutura da UFABC com o da nuvem pública da
70
Amazon WS, os resultados utilizando máquinas virtuais mais robustas são similares aos de sem
cloudburst. No entanto, ao usar a infraestrutura da Amazon houve oscilação nos TRs refletindo
no aumento do intervalo de confiança. Contudo as VMs com maior poder computacional
demonstram ser mais estáveis que as demais.
Comparando Figura 23(b) com Figura 15(a) podemos constatar que mesmo sem utilizar
a técnica de cloudburst o número de máquinas virtuais criadas para os experimentos com limiar
positivo de 350 requisições simultâneas é próximo com os resultados usando a nuvem pública
da Amazon. Ao observarmos a Figura 23(c) é possível constatar a viabilidade do uso da técnica
de cloudburst para os limiares adotados nos experimentos. Mais de 86% dos tempos de resposta
ficaram abaixo de 4,4 segundos e 93% dentro do limite de 10 segundos.
Número de máquinas virtuais
12
10
Segundos
8
6
4
2
0
13
12
11
10
9
8
(a) Média dos tempos de resposta
(b) Média dos recursos computacionais
16
1
14
0,9
0,8
Histograma e CDF
12
0,7
10
0,6
8
0,5
6
0,4
0,3
4
0,2
2
0,1
0
0
2
5
8
11
14
Mais
Tempo de Resposta
(c) Histograma e CDF dos tempos de resposta
Figura 23 – Média do tempo de resposta e número de máquinas virtuais sem histerese e com
cloudburst.
71
5.4. Custo vs. Benefício
Com intuito de identificar o melhor custo/benefício entre os diversos limiares utilizados
nos experimentos, foi multiplicada a média do número de máquinas virtuais de cada
experimento pela média do tempo de resposta do mesmo experimento (Figura 24). Desta forma,
é obtido o valor que representa o custo/benefício dos limiares. Os resultados obtidos indicam
que quanto menor o valor resultante desta multiplicação melhor são os limiares (Figura 24(a)).
Sendo assim, dentre todos os limiares utilizados nos experimentos os melhores são: 125 e 350
para elasticidade negativa e positiva respectivamente. O que apresentou o resultado menos
insatisfatório no experimento com histerese foi com os limiares, 150 e 250 para elasticidade
negativa e positiva respectivamente (Figura 24(b)). No entanto mesmo assim estes limiares
apresentaram resultados inviáveis. Pois ao compararmos os valores do custo benefício dos
experimentos com os melhores resultados, temos com histerese 183 e o sem histerese 14. Fica
evidente a discrepância entre os valores, sendo assim usar histerese não resultaria em bons
tempos de respostas. Já para os experimentos com cloudburst a relação de custo benefício
demonstra ser satisfatória, utilizando as instâncias do tipo medium e large (Figura 24(c)). No
entanto, ao levarmos em consideração o preço de cada um dos tipos (Tabela 1), podemos
afirmar que um ambiente usando apenas instâncias do tipo medium o valor a ser investido será
250
250
Tempo de resposta vezes número de
máquinas vituais
Tempo de resposta vezes número de
máquinas vituais
a metade do investimento caso o tipo de instância fosse a large.
200
200
150
150
100
100
50
0
Experimento
(a) Experimentos sem histerese
50
0
Experimentos
(b) Experimento com histerese
72
Tempo de resposta vezes número de
máquinas vituais
250
200
150
100
50
0
Experimentos
(c) Experimento com cloudburst
Figura 24 – Relação de custo benefício baseado no número de máquinas virtuais e tempo de
resposta
73
Capítulo 6
Conclusão e Trabalhos Futuros
O conceito de computação em nuvem ganhou força no ambiente empresarial nos últimos
anos devido às funcionalidades que o ambiente apresenta possui. Devido às suas características
o ambiente de nuvem pareceu ser compatível com as necessidades de TIC em Smart Grid. Este
trabalho avaliou a sua real capacidade de prover tal serviço, e principalmente a viabilidade do
emprego da técnica de elasticidade. Foi constatado que a infraestrutura de nuvem, seja pública,
privada ou híbrida, é capaz de atender as necessidades de Smart Grid para o cenário em que foi
realizada a avaliação.
O cálculo para identificar o melhor custo/benefício é um artifício importante para
reduzir os investimentos no ambiente de nuvem. A utilização desta técnica representa que será
utilizada a menor quantidade de máquinas virtuais para prover o serviço, sem comprometer a
qualidade de experiência do usuário.
A escolha das métricas corretas para a realização da elasticidade deve ser uma
preocupação. Tendo em vista que ao considerar a utilização de CPU para este fim pode ocorrer
instabilidade na criação e liberação das máquinas virtuais. Pois esta métrica em específico
apresentou ser bastante sensível às oscilações, tal comportamento resultaria na execução da
elasticidade de forma desnecessária.
Para utilizar a nuvem pública para atender as requisições é necessário elucidar qual tipo
de instância consegue atender as necessidades do negócio. Esta escolha resultará diretamente
no investimento necessário no ambiente de nuvem pública. Não se deve escolher um tipo menos
robusto apenas observando o quanto será investido. Pois esta pode não possuir os recursos
computacionais necessários para disponibilizar os serviços resultando assim em degradação do
serviço prestado.
Ao analisar os controladores de nuvens privadas é possível identificar a necessidade de
melhorarias para o desenvolvimento de todas as suas funcionalidades de um ambiente de
nuvem. Até mesmo o OpenStack que é amparado por organizações como NASA e Rackspace
necessita de severas melhorias. Outro fator a ser mencionado em uma infraestrutura de nuvem
privada é a sua alta complexidade de configuração. Sendo assim resulta no aumento do
investimento em profissionais para a sua manutenção.
Ao comparamos os preços da utilização dos serviços das nuvens públicas existentes hoje
com as necessidades de Smart Grid, podemos constatar que será preciso um alto investimento
74
para manter toda a infraestrutura na nuvem pública. Desta forma torna-se vantajoso utilizar o
conceito de cloudburst para minimizar o uso da nuvem pública. A composição de nuvem
privada com nuvem pública formando as nuvens híbridas demonstra ser capaz de obter o melhor
custo/benefício. Pois estas possuem toda disponibilidade de recursos computacionais existentes
na nuvem pública para atender apenas aos picos de consumo. Quanto o controle da
infraestrutura da nuvem privada para a execução da carga média existente durante o dia.
Foi possível constatar com os experimentos realizados, que no cenário avaliado a
utilização da técnica de histerese para controlar a elasticidade resulta em instabilidade no
ambiente, independentemente dos limiares usados para adicionar novas máquinas virtuais. Foi
identificada que as instâncias do tipo medium apresentam o melhor custo benefício para a
realização de cloudburst. Tendo em vista o tempo de resposta e o investimento em infraestrutura
de nuvem pública. Ao analisar os resultados que utilizaram somente a nuvem privada da
UFABC constatou-se que adotando os limiares 125, 400 para elasticidade negativa e positiva
respectivamente, é possível obter, na média, tempos de resposta dentro do limite estabelecido
de 10 segundos sem a necessidade de criar mais máquinas virtuais do que o necessário.
Comparando os tempos de resposta obtidos nos experimentos da seção 5.1 com os da 5.3, é
constatado que apesar do cliente não possuir o controle sobre a infraestrutura na nuvem pública,
esta proporciona estabilidade suficiente para manter a qualidade de experiência do usuário.
6.1 Principais resultados
Este trabalho apresentou o impacto da elasticidade no tempo de resposta em um
ambiente de Smart Grid utilizando diferentes infraestruturas de nuvem. As variações dos
valores de limiares de elasticidade bem como a escolha do tipo de instância na nuvem pública
refletem diretamente tanto na qualidade de experiência do usuário quanto no valor investido em
infraestrutura de nuvem. Determinar o melhor custo benefício entre investimento e qualidade
de experiência é primordial para reduzir gastos sem impactar na qualidade do serviço prestado.
Dentre os principais resultados pode-se destacar:

A diferença entre as métricas para a realização da elasticidade, ao utilizarmos o número
de requisições simultâneas foi possível controlar de forma mais estável a elasticidade.

Evidenciamos que a métrica de utilização de CPU como parâmetro para a elasticidade
pode causar instabilidade no ambiente devido a sua sensibilidade a oscilações.
75

A utilização de cloudburst para atender a picos de consumo apresenta resultado
satisfatório diante da estabilidade que este demonstra ter quando escolhido tipos de
instâncias mais robustas.

Os controladores de nuvem privada ainda não possuem as funcionalidades necessárias
para atender os requisitos de nuvem, em específico a elasticidade. Sendo essa necessária
à implementação por parte do usuário para cada controlador.

Proposta e avaliação de um ambiente de nuvem híbrida para o gerenciamento de Smart
Grid, juntamente com as características da computação autonômica.

Foi identificado o cálculo para definir o custo benefício entre investimento em recursos
computacionais e qualidade de experiência do usuário.

6.2. Trabalhos Futuros
Durante o desenvolvimento do trabalho foi observado a possibilidade de expansão do
mesmo para diferentes vertentes. Com a análise dos resultados foi identificada a necessidade
da execução de diferentes experimentos utilizando vários ambientes de nuvem. No entanto,
estes não estavam presentes no escopo deste trabalho.

Realizar a modelagem matemática do problema com intuito de identificar o ponto
ótimo, onde apresenta o melhor custo benefício para a utilização da infraestrutura de
nuvem.

Executar os experimentos com diferentes configurações de máquinas virtuais na nuvem
privada da UFABC.

Verificar o impacto ao usar diferentes controladores de nuvem como: OpenStack, este
atualmente em acessão.

Efetuar experimentos utilizando a nuvem privada já sobrecarregada, com intuito de
identificar comportamento anômalo neste cenário.

Utilizar outro hipervisor para constatar a diferença de desempenho entre as diferentes
tecnologias existentes.
76
Referências Bibliográficas
[1] A. Kivity, Y. Kamay, D. Laor, U. Lublin and A. Liguori, kvm: the Linux Virtual Machine
Monitor. In Linux Symposium, pages 225-230, 2007.
[2] Amazon Elastic Compute Cloud. Disponível em: aws.amazon.com/ec2, acessado em: Junho
de 2013.
[3] Amazon Web Service. Disponível em: aws.amazon.com, acessado em: Junho de 2013.
[4] Amazon CloudWatch. Disponível em: aws.amazon.com/pt/cloudwatch, acessado em:
Junho de 2013.
[5] Apache ODE. Disponível em: www.ode.apache.org, acessado em: Junho de 2013.
[6] Apache Tomcat. Disponível em: www.tomcat.apache.org, acessado em: Junho de 2013.
[7] Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz, R., Konwinski, A., Lee, G.,
Patterson, D., Rabkin, A., Stoica, I., Zaharia, M., “A View of Cloud Computing”,
Communications of the ACM, 53(4), p. 50-58, Abril de 2010.
[8] Arnold, G. W., “Challenges and Opportunities in Smart Grid: A Position Article”,
Proceedings of the IEEE, 99(6), Junho de 2011.
[9] Azevedo, E., Dias, C., Simões, R., Dantas, R. Sadok, D., Fernandes, S., Kamienski, C.,
“Nuvem Pública versus Privada: Variações no Desempenho de Infraestrutura para
Elasticidade” Brazilian Symposium on Computer Networks and Distributed Systems, Maio
de 2012.
[10] Baker, J., Bond, C., Corbett, J., Furman, J., Khorlin, A., Larson, J., Leon, J-M., Li, Y.,
Lloyd, A., Yushprakh, V.. Megastore: Providing Scalable, Highly Available Storage for
Interactive Services. In CIDR, pages 223–234, 2011.
[11] Barcomb, K.E.; Humphries, J.W.; Mills, R.F.; , "A case for DoD application of public
cloud computing services," MILITARY COMMUNICATIONS CONFERENCE, 2011 MILCOM 2011 , vol., no., pp.1888-1893, 7-10, Novembro de 2011.
[12] Barham P., Dragovic B., Fraser K., Hand S., Harris T., Ho A., Neugubauer R., Pratt I.,
Warfiled A., “Xen and the art of virtualization”, SOSP '03 19th ACM symposium on
Operating systems principles, Dezembro de 2003.
[13] Birman, K. P., Ganesh, L., van Renesse, R., “Running Smart Grid Control Software on
Cloud Computing Architectures”, Workshop on Computational Needs for the Next
Generation Electric Grid, Cornell University, Abril de 2011.
[14] Chaudhary, V.; Minsuk Cha; Walters, J.P.; Guercio, S.; Gallo, S.; , "A Comparison of
Virtualization Technologies for HPC," Advanced Information Networking and
77
Applications, 2008. AINA 2008. 22nd International Conference on , vol., no., pp.861-868,
25-28, Março de 2008.
[15] Chowdhury, N. M. K., Boutaba, R.. “Network Virtualization: State of the art and research
challenges”. IEEE Communication Magazine, Julho de 2009.
[16] F. Chang, J. Dean, S. Ghemawat, W. Hsieh, D. Wallach, M. Burrows, T. Chandra, A.
Fikes, and R. Gruber. Bigtable: A Distributed Storage System for Structured Data.
Proceedings of 7th Symposium on Operating System Design and Implementation (OSDI),
page 205218, 2006.
[17] F. Curbera et al., “Unraveling the Web Services Web,” IEEE Internet Computing, vol. 6,
no. 2, pp. 86–93, 2002.
[18] F. Leymann, “Cloud Computing: The Next Revolution in IT,” in Proc. 52th
Photogrammetric Week. W. Verlag, , pp. 3–12 Setembro de 2009
[19] Fangxing Li; Wei Qiao; Hongbin Sun; Hui Wan; Jianhui Wang; Yan Xia; Zhao Xu; Pei
Zhang; , "Smart Transmission Grid: Vision and Framework," Smart Grid, IEEE
Transactions on , vol.1, no.2, pp.168-177, Setembro de 2010.
[20] Force.com. Disponível em: www.force.com, acessado em: Junho de 2013.
[21] Foster, I.; Yong Zhao; Raicu, I.; Shiyong Lu, "Cloud Computing and Grid Computing 360Degree Compared," Grid Computing Environments Workshop, 2008. GCE '08 , vol., no.,
pp.1,10, 12-16 Novembro de. 2008
[22] Galante, G.; de Bona, L.C.E., "A Survey on Cloud Computing Elasticity," Utility and
Cloud Computing (UCC), 2012 IEEE Fifth International Conference on , vol., no.,
pp.263,270, 5-8 Novembro de 2012.
[23] GoGrid. Disponível em: www.gogrid.com, acessado em: Junho de 2013.
[24] Google App Engine. Disponível em: developers.google.com/appengine, acessado em:
Junho de 2013.
[25] Hassan, S.; Al-Jumeily, D.; Hussain, A.J., "Autonomic Computing Paradigm to Support
System's Development," Developments in eSystems Engineering (DESE), 2009 Second
International Conference on , vol., no., pp.273,278, 14-16 Dezembro de 2009.
[26] Ipakchi, A., Albuyeh, F., “Grid of the Future: Are We Ready to Transition to a Smart
Grid?”, IEEE Power & Energy Magazine, 7(2), p. 52 – 62, Março-Abril de 2009.
[27] Jianfeng Yang; Zhibin Chen, "Cloud Computing Research and Security Issues,"
Computational Intelligence and Software Engineering (CiSE), 2010 International
Conference on , vol., no., pp.1,3, 10-12 Dezembro de 2010.
[28] Jianhua Che; Yong Yu; Congcong Shi; Weimin Lin, "A Synthetical Performance
Evaluation of OpenVZ, Xen and KVM," Services Computing Conference (APSCC), 2010
IEEE Asia-Pacific , vol., no., pp.587,594, 6-10 Dezembro de. 2010.
78
[29] Keahey, K. “Nimbus: Open Source Infrastructure-as-a-Service Cloud Computing
Software”, Workshop on adapting applications and computing services to multi-core and
virtualization, CERN, Switzerland 2009.
[30] Kephart, J. & Chess, D., “The Vision of Autonomic Computing”, IEEE Computer
Magazine, 36(1), p. 41-50, Janeiro de 2003.
[31] Khalidi, Y., "Building a Cloud Computing Platform for New Possibilities," Computer ,
vol.44, no.3, pp.29-34. Março de 2011.
[32] Kim, H.; Parashar, M.; Foran, D.; Yang, L., “Investigating the Use of Autonomic
Cloudbursts for High-Throughput Medical Image Registration”, 10th IEEE/ACM
International Conference on Grid Computing, Outubro de 2009.
[33] KVM. Disponível em: linux-kvm.org, acessado em: Junho de 2013.
[34] L. Yu and et al., “Harnessing parallelism in multicore clusters with the all-pairs, wavefront,
and makeflow abstractions,” Journal of Cluster Computing, vol. 13, no. 3, pp. 243–256,
2010.
[35] Mahjoub, M.; Mdhaffar, A.; Halima, R.B.; Jmaiel, M., "A Comparative Study of the
Current Cloud Computing Technologies and Offers," Network Cloud Computing and
Applications (NCCA), 2011 First International Symposium on , vol., no., pp.131,134, 2123 Novembro de 2011.
[36] Mahjoub, M.; Mdhaffar, A.; Halima, R.B.; Jmaiel, M.; , "A Comparative Study of the
Current Cloud Computing Technologies and Offers," Network Cloud Computing and
Applications (NCCA), 2011 First International Symposium on , vol., no., pp.131-134, 2123, Novembro de 2011.
[37] Mathew, R.; Spraetz, R., "Test Automation on a SaaS Platform," Software Testing
Verification and Validation, 2009. ICST '09. International Conference on , vol., no.,
pp.317-325, 1-4. Abril de 2009.
[38] Microsoft Azure. Disponível em: www.windowsazure.com, acessado em: Junho de 2013.
[39] Minqi Zhou; Rong Zhang; Dadan Zeng; Weining Qian; , "Services in the Cloud
Computing era: A survey," Universal Communication Symposium (IUCS), 2010 4th
International , vol., no., pp.40-46, 18-19, Outubro de 2010.
[40] Moghe, U.; Lakkadwala, P.; Mishra, D.K., "Cloud computing: Survey of different
utilization techniques," Software Engineering (CONSEG), 2012 CSI Sixth International
Conference on , vol., no., pp.1,4, 5-7 Setembro de 2012.
[41] Nance, K.; Bishop, M.; Hay, Brian, "Virtual Machine Introspection: Observation or
Interference?," Security & Privacy, IEEE , vol.6, no.5, pp.32,37, Setembro.- Outubro de
2008.
[42] Nimbus. Disponível em: www.nimbusproject.org, acessado em: Junho de 2013.
[43] Nurmi, D.; Wolski, R.; Grzegorczyk, C.; Obertelli, G.; Soman, S.; Youseff, L.;
Zagorodnov, D.; , "The Eucalyptus Open-Source Cloud-Computing System," Cluster
79
Computing and the Grid, 2009. CCGRID '09. 9th IEEE/ACM International Symposium
on , vol., no., pp.124-131, 18-21, Maio de 2009.
[44] OCCI. Disponível em: occi-wg.org, acessado em: Junho de 2013.
[45] Ogrizović, D.; Sviličić, B.; Tijan, E., "Open source science clouds," MIPRO, 2010
Proceedings of the 33rd International Convention , vol., no., pp.1189,1192, 24-28 Maio de
2010.
[46] OpenNebula Project (2012). “The Open Source Toolkit for Cloud Computing”,
http://opennebula.org/.
[47] OpenStack. Disponível em: www.openstack.org, acessado em: Junho de 2013.
[48] P. Mell and T. Grance, “The NIST Definition of Cloud Computing,” US Nat’l Inst. of
Science and Technology, 2011; http://csrc.nist.gov/publications/nistpubs/800-145/SP800145.pdf
[49] P. Mell and T. Grance. NIST definition of cloud computing. National Institute of Standards
and Technology, Setembro de 2011.
[50] P. T. Endo, G. E. Gon¸calves, J. Kelner, and D. Sadok. A Survey on Open-source Cloud
Computing Solutions. Brazilian Symposium on Computer Networks and Distributed
Systems, Maio de 2010.
[51] Patidar, S.; Rane, D.; Jain, P.; , "A Survey Paper on Cloud Computing," Advanced
Computing & Communication Technologies (ACCT), 2012 Second International
Conference on , vol., no., pp.394-398, 7-8, Janeiro de 2012.
[52] Peng, J.; Zhang, X.; Lei, Z.; Zhang, B.; Zhang, W.; Li, Q.; , "Comparison of Several Cloud
Computing Platforms," Information Science and Engineering (ISISE), 2009 Second
International Symposium on , vol., no., pp.23-27, 26-28, Dezembro de 2009.
[53] PlanetLab. Disponível em: www.planet-lab.org, acessado em: Junho de 2013.
[54] Rackspace. Disponível em: www.rackspace.com, acessado em: Junho de 2013.
[55] Rajan, D.; Canino, A.; Izaguirre, Jesus A.; Thain, D., "Converting a High Performance
Application to an Elastic Cloud Application," Cloud Computing Technology and Science
(CloudCom), 2011 IEEE Third International Conference on , vol., no., pp.383,390,
Novembro de 2011-Dezembro de. 2011
[56] Rappa, M.A., "The utility business model and the future of computing services," IBM
Systems Journal , vol.43, no.1, pp.32,42, 2004
[57] Raveendran, A.; Bicer, T.; Agrawal, G., "A Framework for Elastic Execution of Existing
MPI Programs," Parallel and Distributed Processing Workshops and Phd Forum
(IPDPSW), 2011 IEEE International Symposium on , vol., no., pp.940,947, 16-20 Maio de
2011
[58] Regola, N.; Ducom, J.-C.; , "Recommendations for Virtualization Technologies in High
Performance Computing," Cloud Computing Technology and Science (CloudCom), 2010
80
IEEE Second International Conference on , vol., no., pp.409-416, Nov. 30 2010-Dec. 3
2010
[59] Rimal, B.P.; Eunmi Choi; Lumb, I., "A Taxonomy and Survey of Cloud Computing
Systems," INC, IMS and IDC, 2009. NCM '09. Fifth International Joint Conference on ,
vol., no., pp.44,51, 25-27 Agosto de 2009.
[60] Rusitschka, S., Eger, K., Gerdes, C., “Smart Grid Data Cloud: A Model for Utilizing Cloud
Computing in the Smart Grid Domain”, IEEE First International Conference on Smart Grid
Communications (SmartGridComm), p. 483 – 488, Outubro de 2010.
[61] Salesforce. Disponível em: www.salesforce.com, acessado em: Junho de 2013.
[62] Santacana, E.; Rackliffe, G.; Le Tang; Xiaoming Feng; , "Getting Smart," Power and
Energy Magazine, IEEE , vol.8, no.2, pp.41-48, Março-Abril de 2010.
[63] Sempolinski, P.; Thain, D., "A Comparison and Critique of Eucalyptus, OpenNebula and
Nimbus," Cloud Computing Technology and Science (CloudCom), 2010 IEEE Second
International Conference on , vol., no., pp.417,426, Nov. 30 2010-Dezembro de 2010.
[64] Sotomayor, B.; Montero, R.S.; Llorente, I.M.; Foster, I.; , "Virtual Infrastructure
Management in Private and Hybrid Clouds," Internet Computing, IEEE , vol.13, no.5,
pp.14-22, Outubro de 2009.
[65] Wind, S., "Open source cloud computing management platforms: Introduction,
comparison, and recommendations for implementation," Open Systems (ICOS), 2011
IEEE Conference on , vol., no., pp.175,179, 25-28 Setembro de 2011.
[66] Xen Hipervisor. Disponível em: xen.org/products/xenhyp.html, acessado em: Junho de
2013.
[67] Xiaolong Wen; Genqiang Gu; Qingchun Li; Yun Gao; Xuejie Zhang, "Comparison of
open-source cloud management platforms: OpenStack and OpenNebula," Fuzzy Systems
and Knowledge Discovery (FSKD), 2012 9th International Conference on , vol., no.,
pp.2457,2461, 29-31 Maio de 2012.
[68] Xiaolong Wen; Genqiang Gu; Qingchun Li; Yun Gao; Xuejie Zhang, "Comparison of
open-source cloud management platforms: OpenStack and OpenNebula," Fuzzy Systems
and Knowledge Discovery (FSKD), 2012 9th International Conference on , vol., no.,
pp.2457,2461, 29-31 Maio de 2012.
[69] Yan Wen; Jinjing Zhao; Gang Zhao; Hua Chen; Dongxia Wang, "A Survey of
Virtualization Technologies Focusing on Untrusted Code Execution," Innovative Mobile
and Internet Services in Ubiquitous Computing (IMIS), 2012 Sixth International
Conference on , vol., no., pp.378,383, 4-6 Julho de 2012.
[70] Zhenxing Zhao; Congying Gao; Fu Duan, "A survey on autonomic computing research,"
Computational Intelligence and Industrial Applications, 2009. PACIIA 2009. Asia-Pacific
Conference on , vol.2, no., pp.288,291, 28-29 Novembro de 2009.