Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA 2014
Gerenciamento de Elasticidade em Nuvens Privadas e
Híbridas
Rhodney Simões £, Carlos Kamienski¥
£
Universidade Federal de Alagoas (UFAL)
[email protected]
¥
Universidade Federal do ABC (UFABC)
[email protected]
Resumo. Computação em nuvem requer o gerenciamento da elasticidade para
que recursos computacionais sejam alocados e liberados dinamicamente.
Embora a adoção de serviços de nuvem esteja aumentando, o conhecimento
disponível ainda não é suficiente para orientar o gerenciamento da
elasticidade. Este artigo faz uma avaliação de elasticidade em nuvem privada
e híbrida, usando o ambiente de laboratório, o PlanetLab e o serviço Amazon
EC2. Os resultados mostram que a escolha de métricas e limiares é
fundamental na manutenção da qualidade aliada ao controle de custos e que
cloudburst pode ser usado para implementar uma nuvem híbrida mas a
escolha do tipo de máquina virtual no provedor tem impacto significativo.
Abstract. Cloud computing requires elasticity management for dynamically
allocating and releasing computational resources. However, even though the
adoption of cloud services has been growing, the available knowledge is not
enough for guiding users when they need to manage elasticity. This paper
analyzes elasticity in private and hybrid clouds, using a university lab,
PlanetLab and Amazon EC2. Results show that the choice of metrics and
thresholds plays a key role for keeping quality levels and controlling costs and
that cloudburst can be effectively used for implementing a hybrid cloud but the
choice of the type of virtual machine in the provider has a significant impact.
1. Introdução
Computação em nuvem oferece a visão de computação como utilidade [Armbrust
2010], onde recursos computacionais são alocados e liberados dinamicamente e o
usuário paga somente o que usar. Essa característica é provida através da elasticidade,
que pode ser positiva, quando um novo recurso é criado para atender a um aumento de
demanda, ou negativa, quando um recurso é liberado por estar ocioso. Computação em
nuvem apresenta características únicas, além da elasticidade, como autosserviço sob
demanda, amplo acesso via rede, recursos disponíveis e medição de uso de serviço
[Mell & Grance, 2011].
Em geral as nuvens são classificadas em quatro categorias [Mell & Grance 2011]:
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 As nuvens híbridas surgem da composição de
nuvens privadas e públicas, algo que geralmente ocorre quando uma empresa compra
capacidade adicional num provedor de nuvem pública para atender picos de demanda na
sua nuvem privada. Nuvens comunitárias são aquelas que permitem uso compartilhado
67
Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA 2014
por usuários que colaboram para obter um ambiente computacional de maior
capacidade. Este artigo faz uso das quatro categorias.
Embora existam vários provedores de nuvem pública que oferecem serviços pela
Internet e a adoção de nuvem privada seja crescente nas organizações, há pouca
informação disponível para orientar o gerenciamento da elasticidade de um ponto de
vista prático. A principal questão é como e quando criar novos recursos computacionais
para atender a demanda e liberá-los quando não mais são necessários para que o usuário
não pague mais do que necessita. É necessária a definição de métricas e configuração de
limiares para tomada de ações de elasticidade. No caso de IaaS o próprio usuário deve
administrar o uso dos seus recursos computacionais, como máquinas virtuais.
Provedores de nuvens públicas oferecem serviços adicionais para controlar a
elasticidade, mas não há informações detalhadas sobre essas ações, inclusive pela
dependência que existe de aplicações específicas. Por exemplo, pode-se usar métricas
de nível de sistema operacional que são gerenciadas diretamente pelo provedor como
uso de CPU e memória, ou então capturar métricas de aplicação e usá-las no
gerenciamento da elasticidade. Por outro lado, também existe pouca informação e
compreensão do funcionamento de nuvens híbridas, onde nuvens privadas direcionam
parte da sua demanda para nuvens públicas através de cloudburst [Kim, H. et. al. 2009].
Este artigo apresenta resultados de avaliação de desempenho de elasticidade em
nuvem privada e híbrida, usando o PlanetLab1 para geração de carga de trabalho dos
clientes e o serviço Amazon EC22 de nuvem pública. Como cenário e motivação foi
implementado um sistema que gerencia Smart Grid [Ipakchi, A., Albuyeh, F. 2009] na
nuvem. Os resultados mostram que métricas e limiares devem ser cuidadosamente
utilizados para obter o efeito desejado de manutenção da qualidade do serviço ao
mesmo tempo que se controla os custos. Particularmente, descobrimos que as métricas
de utilização de memória e CPU geram instabilidade na criação e liberação de máquinas
virtuais e por isso passamos a usar uma métrica de aplicação, número de requisições,
que gerou resultados estáveis. Os resultados evidenciam que a qualidade para o cliente e
o custo são muito sensíveis aos limiares, ficando evidente que existem certos limites
onde não vale a pena economizar ou gastar mais recursos computacionais. Além disso, a
técnica de cloudburst pode ser usada para equalizar os recursos disponíveis com a
demanda, mas a escolha do tipo de máquina virtual no provedor tem papel decisivo na
obtenção de uma relação custo/benefício satisfatória. A principal contribuição desse
artigo é apresentar resultados reais de experimentos executados em ambiente distribuído
que podem efetivamente orientar administradores de ambientes de nuvem a melhor
gerenciar os seus recursos.
Na sequência do artigo, a seção 2 trata do gerenciamento da elasticidade e
apresenta trabalhos relacionais. A seção 3 apresenta a metodologia de avaliação e a
seção 4 apresenta os resultados. A seção 5 discute os principais resultados e finalmente
a seção 6 apresenta conclusões e trabalhos futuros.
2. Gerenciamento de Elasticidade em Nuvem
O conceito de elasticidade em nuvem [Mell & Grance, 2011] [Leymann 2009] emprega
a liberdade do cliente de alocar e liberar recursos diante da sua necessidade, sem que
1
2
http://planet-lab.org
http://aws.amazon.com/ec2
68
Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA 2014
seja necessária a intervenção do provedor de serviço. Recursos de computação e de
armazenamento são os que mais comumente podem ser alocados e liberados
dinamicamente em um datacenter. Embora não seja uma condição essencial para
caracterizar a computação em nuvem, já tornou-se padrão que os recursos de
computação sejam oferecidos através de máquinas virtuais (VM).
Provedores comerciais de nuvens públicas oferecem serviços de elasticidade,
como é o caso da Amazon AWS3, por meio do serviço CloudWatch4. O CloudWatch
tem como principal funcionalidade monitorar métricas como a utilização de CPU e
memória e quantidade de requisições que são efetuadas para uma determinada máquina
virtual. Diante dessas métricas o usuário pode configurar limiares para que uma nova
VM seja criada ou liberada para atender demandas flutuantes. Infelizmente este recurso
não é oferecido diretamente por controladores de nuvem privada como OpenNebula5 e
OpenStack6 e o administrador de nuvem privada quiser usufruir de tal funcionalidade
ele terá de implementá-lo.
A utilização de nuvem híbrida pode fornecer um ambiente robusto o suficiente
para suportar picos de demanda. Uma organização pode fazer um investimento em
infraestrutura para suportar determinada demanda e tudo o que exceder a sua capacidade
pode ser comprado da nuvem pública. A técnica de criar VMs em uma nuvem pública
para atender a demandas que excedem a capacidade de uma nuvem privada é conhecida
como cloudburst7 [Kim, H. et. al. 2009]. Cloudburst permite 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 sido exauridos. Desta forma, não haverá o uso da nuvem pública a
menos que seja realmente necessária a sua utilização.
Existem trabalhos na literatura que tratam do gerenciamento da elasticidade,
porém não com a abordagem desse artigo, que oferece informações úteis para
configurar efetivamente os mecanismos de elasticidade. Muitos artigos apresentam
resultados de simulação ou modelos matemáticos e outros focam em predição, mas não
apresentam informações para auxiliar a configuração da elasticidade. Em [Morais et. al
2013] é apresentado um arcabouço para provisionamento automático de recursos em
nuvem usando métricas que não dependem da aplicação (como CPU e memória) e são
apresentados resultados de simulação. Neste artigo, com base em experimentos reais em
ambiente distribuído, defendemos o uso de métricas de aplicação, por estarem mais
próximas do usuário e portanto facilitarem a configuração efetiva dos níveis adequados
para atender as demandas de SLA e fazer uso eficiente dos recursos. Em um ambiente
real é possível perceber o comportamento efetivo de mecanismos que em um ambiente
simulado podem ter um comportamento idealizado, devido às simplificações
necessárias. CloudFlex (Seoung et al. 2011) é uma proposta para gerenciar os recursos
na nuvem para atender demandas acima da capacidade instalada, mas que não se dedica
a estudar especificamente os mecanismos de elasticidade. DEPAS (Calcavecchia et. al
2012) é um algoritmo decentralizado e probabilístico para elasticidade (chamado aqui
de auto scaling) e que se integra um uma rede P2P. O artigo avalia o mecanismo por
3
http://aws.amazon.com
http://aws.amazon.com/pt/cloudwatch
http://opennebula.org
6
http://www.openstack.org
7
A tradução de cloudburst em português é aguaceiro. Dada a ausência de um termo adequado, usamos o original em inglês.
4
5
69
Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA 2014
simulação e experimentação, mas os resultados não focam na escolha das métricas e dos
limiares. Por último o trabalho apresentado em [Galante, G.; de Bona, L.C.E. 2012]
categorizou a elasticidade em computação em nuvem.
Este artigo foca na avaliação e no efeito dos limiares, baseados na métrica de
número de requisições simultâneas, que apresenta maior confiabilidade para evitar a
ação da elasticidade de forma desnecessária.
3. Metodologia de avaliação
3.1. Ferramenta
O cenário de avaliação da elasticidade ocorre no contexto de Smart Grid, a rede elétrica
inteligente, para o qual foi desenvolvido o Smart Grid Autonomic Management System
(SGAMS). O SGAMS possui três módulos (geração, distribuição e clientes),
responsáveis por tarefas distintas, mas que se completam para compor o ambiente de
redes inteligentes de energia elétrica. 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. O
módulo de distribuição é 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.
3.2. Ambiente
O módulo de geração foi implementado utilizando a infraestrutura da nuvem privada da
universidade com a linguagem Java. O módulo de distribuição também foi implantado
na infraestrutura de nuvem privada 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 (Linux Debian) para evitar
que o Tomcat fique indisponível. Por último foi utilizado o PlanetLab como um
exemplo similar a nuvem comunitária para o módulo cliente, onde cada máquina
representa um conjunto de consumidores de energia. A avaliação de cloudburst em
nuvem híbrida foi implementada usando o Amazon Elastic Compute Cloud (EC2), que
oferece alguns padrões de instâncias (máquinas virtuais, na terminologia da Amazon) a
serem alocadas para o cliente. Neste trabalho foram utilizadas três tipos de instâncias
com capacidades de processamento crescente (small, medium e large), com o intuito de
analisar o impacto dos diferentes tipos na realização de elasticidade.
3.3. Cenário
Um dos principais objetivos do trabalho é identificar os melhores valores para os
limiares positivos e negativos para alocar e liberar VMs para oferecer um tempo de
resposta adequado para os clientes do módulo de distribuição. Foram executados
experimentos preliminares com intuito de definir qual seria o tempo de resposta mínimo
(TRm), além de determinar o número máximo de requisições simultâneas que uma VM
70
Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA 2014
pode suportar antes que o tempo de resposta ultrapasse um limite máximo, que para a
aplicação de Smart Grid foi definido como 10 segundos8.
Dois experimentos preliminares foram realizados. O primeiro teve como foco
determinar o TRm e para isto 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, porque alguns demonstravam
possuir recursos de rede insuficientes para a realização dos experimentos, resultando
assim em valores excessivamente altos (outliers). O segundo experimento teve como
foco determinar a quantidade máxima de requisições que uma VM consegue 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.
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 quando os recursos da nuvem privada foram exauridos (Figura 1). Este
experimento tem como objetivo estudar 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 1 – Arquitetura do SGAMS com cloudburst
3.4. 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 (TR): 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.
8
Não existe bibliografia sobre o assunto e em se tratando de algo que ainda não existe definimos um limite de tempo (que poderia
ser um valor ligeiramente diferente) para fins de avaliação do mecanismo de elasticidade.
71
Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA 2014
•
•
•
•
•
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 que realiza o balanceamento de carga.
Nós do PlanetLab: número de nós do PlanetLab alocados para gerar a carga de
trabalho, onde cada nós no PlanetLab é usado para modelar o comportamento de
um determinado número de clientes do Smart Grid. Por exemplo, cada nó envia
uma requisição ao servidor a cada 3 segundos. Se considerarmos um ambiente
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.
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 do TR
no decorrer do experimento. O cálculo da média, mediana e percentil 90, proporciona a
identificação de outliers, de modo a possibilitar a identificação de alguma instabilidade
nos clientes alocados para a realização do experimento A partir da quantidade de
clientes e a quantidade de requisições simultâneas existentes para a geração de carga é
possível comprovar a necessidade ou não da realização da elasticidade. É importante
notar que a elasticidade deveria ser idealmente realizada a partir de uma métrica de
qualidade da experiência para o usuário, que nesse caso é o tempo de resposta. No
entanto, em um ambiente real os valores das métricas dos usuários não necessariamente
estão disponíveis para o provedor e nesse caso uma métrica disponível no provedor foi
utilizada (requisições simultâneas), fazendo-se a comparação com os resultados do
tempo de resposta para os clientes.
A métrica usada para efetuar a elasticidade positiva (criar VM) e negativa (liberar
VM) é o número de requisições simultâneas, que foi dividida pelo número de máquinas
virtuais existentes para elasticidade, resultando no número de requisições por VM. Tal
métrica foi escolhida diante da comparação com a utilização de CPU e memória em
uma série de experimentos preliminares. A taxa de utilização de CPU mostrou-se uma
métrica muito sensível a pequenas oscilações na quantidade de requisições. Por outro
lado, a taxa de utilização de memória apresentou diversos problemas, como excessiva
lentidão na liberação de memória pela aplicação, que causava uma falsa impressão de
falta de memória. A principal questão que levou à escolha do número de requisições
como métrica para a elasticidade é a facilidade de compreensão para o desenvolvedor da
aplicação e administrador de sistemas. Uma vez que se conhece o número de
requisições simultâneas que determinada VM pode tratar com a qualidade desejada para
o usuário, a configuração dos limiares da elasticidade se torna mais simples e direta.
4. Resultados
Os resultados apresentados nessa seção consideram que cada cliente realiza uma
requisição seguindo uma distribuição Exponencial com média de 3 segundos. Foram
efetuadas 10 replicações de cada experimento e intervalos de confiança com nível de
99% foram calculados, sendo que em vários casos são apresentadas séries temporais dos
72
Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA 2014
valores das métricas usando uma replicação que representa a média das demais. Valores
médios também são apresentados, juntamente com os intervalos de confiança. Para a
avaliar a elasticidade sob diferentes condições foram utilizados 5 limiares para
elasticidade positiva (250, 300, 350, 400 e 600) e 3 limiares para elasticidade negativa
(100, 125 e 150). Nos gráficos das séries temporais apenas os resultados para os valores
350 e 150 são mostrados, devido a restrições de espaço. Esses resultados apresentam
relação adequada com o tempo de resposta demonstrando um bom tradeoff para criação
e liberação de máquinas virtuais. Além disso, o os limiares 150 e 350 apresentaram
resultados semelhantes nos experimentos sem e com cloudburst. É importante notar que
os valores atribuídos a limiares são específicos de cada aplicação.
Cada experimento apresenta um tempo médio de aproximadamente 45 minutos,
com 15 minutos adicionais para fazer o download dos logs em todos os nós do
PlanetLab. Ao todo foram executas 230 horas de experimentos. Cem nós do PlanetLab
foram alocados em cada experimento, mas para que isso fosse possível, centenas foram
avaliados e vários nós tiveram que ser eliminados durante os experimentos devido a
problemas internos.
4.1. Elasticidade sem Cloudburst
Observando a Figura 2(a) que apresenta a média, mediana e o percentil 90 do tempo de
resposta, podemos constatar que o resultado obtido neste experimento está abaixo do
tempo máximo aceito de 10 segundos. Sendo assim podemos afirmar que para o
ambiente analisado os limiares de 350 e 150 para elasticidade positiva e negativa,
respectivamente, é satisfatório.
Número de requisições
Média
Mediana
Percentil 90
9
Segundos
6
3
0
Minutos
(a) Tempo de Resposta
(b) Carga de trabalho
100
12
75
9
Número de nós
Número de máquinas
virtuais
Minutos
6
3
50
25
0
0
Minutos
Minutos
(c) Recursos Computacionais (VMs)
(d) Número de nós do PlanetLab
Figura 2 – Elasticidade com limiares 350 (positivo) e 150 (negativo) e sem
cloudburst
Analisando a métrica de número de VMs (Figura 2(c)), podemos observar que foram
cridas menos de 12 máquinas virtuais para atender as quase 4.000 requisições (Figura
2(b)) no ápice do experimento. Essas requisições são compatíveis com o número de nós
73
Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA 2014
alocados no PlanetLab para representar os clientes (Figura 2(d)). A utilização de
memória e CPU não apresentou resultados significativos e por esse motivo essas
métricas não são apresentadas. Os valores das métricas de carga de trabalho e número
de nós no PlanetLab também não serão mais apresentados porque os valores são
semelhantes aos da Figura 2.
4.2. Elasticidade com Cloudburst
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, foram
realizados experimentos variando o tipo de instância no serviço EC2 da Amazon. Desta
forma foi possível identificar o impacto da utilização da nuvem da pública para a
realização da elasticidade.
Nos experimentos com instâncias do tipo small, como pode ser observado na
Figura 3(a), fica evidente a instabilidade gerada nos tempos de resposta quando o
cloudburst é iniciado. Tal comportamento permanece até o momento em que estas VMs
da nuvem pública são liberadas. Sendo assim podemos afirmar que para a nossa
aplicação realizar cloudburst com instâncias do tipo small não apresenta resultados
satisfatórios, devido à instabilidade de desempenho no atendimento das requisições.
Ao observamos Figura 3(b) e compararmos com a Figura 2(b) 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, ou seja, os recursos computacionais das instâncias
small da Amazon não foram suficientes para suportar a carga gerada.
70
8
Segundos
40
10
Número de VMs
50
Amazon WS
Nuvem Privada
12
Média
Mediana
Percentil 90
60
6
30
4
20
2
10
0
0
Minutos
(a)
Minutos
Tempo de Resposta
(b)
Recursos Computacionais (VMs)
Figura 3 – Experimento com limiares positivo e negativo 350, 150
respectivamente e com cloudburst utilizando instâncias do tipo small.
Nos experimentos com instâncias do tipo medium foi possível observar uma
notável diferença no comportamento dos tempos de resposta (Figura 4(a)) em
comparação com a Figura 3(a). Fica evidente que o incremento de recursos
computacionais para cloudburst reflete diretamente nos tempos de resposta para os
clientes. Utilizando instâncias do tipo medium ao invés de small o custo com a
infraestrutura de nuvem para disponibilizar os serviços dobra de valor, mas o resultado é
visivelmente 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 4(b)).
74
Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA 2014
Ao observar a Figura 4(b) em comparação com Figura 3(b) fica evidente que a
grande diferença entre os recursos computacionais de cada um dos tipos de instâncias
influenciou no tempo de resposta. No experimento com instâncias do tipo small foram
criadas três VMs na Amazon 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.
Média
Mediana
Percentil 90
Amazon AWS
12
Nuvem Privada
10
Número de VMs
6
Segundos
4
8
6
2
4
2
0
0
Minutos
(a)
Minutos
Tempo de Resposta
(b)
Recursos Computacionais (VMs)
Figura 4 – Experimento com limiares positivo e negativo 350, 150
respectivamente e com cloudburst utilizando instâncias do tipo medium.
Instâncias do tipo large possuem inerente vantagem em termos de desempenho,
mas a para a aplicação avaliada não proporcionaram ganhos significativos. Ao
observarmos a Figura 5(a) em relação à Figura 4(a) fica evidente que o ganho com
desempenho dos tempos de resposta é pequeno, em torno de 0,047 segundos na média.
Tal ganho não justifica dobrar o investimento em recursos computacionais de nuvem
pública. Em outras palavras, algo que deve ser levado em consideração é a relação
custo/benefício, que no caso significa o investimento em recursos computacionais em
relação à diminuição e estabilidade dos tempos de resposta. Verificando o número de
máquinas virtuais criadas para a elasticidade na Figura 5(b) é possível constatar que não
houve oscilação em relação ao experimento com instâncias do tipo medium.
10
12
Média
Mediana
Percentil 90
6
Amazon AWS
10
Número de VMs
Segundos
8
8
6
4
4
2
2
0
0
Minutos
(a)
Minutos
Tempo de Resposta
(b)
Recursos Computacionais (VMs)
Figura 5 – Experimento com limiares positivo e negativo 350, 150
respectivamente e com cloudburst utilizando instâncias do tipo large
Os gráficos da Figura 6 mostram as médias das 10 replicações para todos os
experimentos realizados, incluindo todos os limiares e com e sem cloudburst. A Figura
6(a) apresenta os tempos de respostas para vários limiares sem cloudburst. É possível
ver que embora a variação entre os limiares positivos até 400 não é significativa. No
entanto, para o liminar 600 houve um aumento considerável nos tempos de resposta,
porque a criação de uma nova VM é postergada até um ponto onde a qualidade para o
75
Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA 2014
usuário é afetada de maneira irreversível. Existe também variação de 50% no uso de
recursos computacionais, de 8 a 12 VMs. Com o liminar positivo de 600 o custo é o
menor possível, mas gerando perda de desempenho.
Como pode ser observado na Figura 6(c) comparando o comportamento do tempo
de resposta na nuvem privada da UFABC com o da nuvem pública da Amazon, 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. Na Figura 6(d) 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.
25
14
12
10
8
6
4
2
0
Número de VMs
20
Segundos
15
10
5
0
12
10
8
6
4
2
0
13
Número de VMs
Segundos
a) Tempo de resposta (vários limiares, sem
b) VMs (vários limiares, sem cloudburst)
cloudburst)
12
11
10
9
8
c) Tempo de resposta (com e sem cloudburst)
d) VMs (com e sem cloudburst)
Figura 6 – Média do tempo de resposta e número de máquinas virtuais (sem e
com cloudburst)
4.3. Custo vs. Benefício
Com intuito de identificar relações de custo/benefício adequadas entre os diversos
limiares utilizados nos experimentos, foi criada uma métrica que multiplica a média do
número de máquinas virtuais de cada experimento pela média do tempo de resposta do
mesmo experimento. Essa métrica não apresenta valores com significado específico,
mas um valor que representa o custo/benefício dos diferentes experimentos realizados.
Quanto menor o valor da métrica, mais adequada é a configuração usada. Embora em
teoria seria possível um valor muito alto para custo em troca de um valor muito baixo
para o benefício fica claro que os tempos de resposta tem tempos mínimos que não
podem ser diminuídos mesmo com grandes investimentos.
76
Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA 2014
160
140
120
100
80
60
40
20
0
Relação custo/benefício
Relação custo/benefício
A Figura 7(a) apresenta os resultados da métrica custo/benefício para os vários
experimentos sem cloudburst. No geral, pequenas variações para baixo ou para cima no
número de VMs (custo) são compensadas por variações na direção contrária do tempo
de resposta (benefício). A exceção é o liminar positivo 600, mostrando que economizar
a partir de um determinado ponto cobra um alto preço na redução da qualidade. Nos
experimentos com cloudburst mostrados na Figura 7(b) em comparação a sem
cloudburst com limiares 350 e 150, pode-se observar que o uso da nuvem híbrida é
adequada para instâncias do tipo medium, mas não para instâncias small. No caso de
instâncias large, embora o valor da métrica seja adequado, ela não computa o custo de
aluguel cobrado pelo provedor. Isso torna as instâncias large inadequadas para o
ambiente avaliado.
a) Custo/benefício sem cloudburst e vários limiares
80
70
60
50
40
30
20
10
0
b) Custo/benefício com e sem cloudburst
Figura 7 – Relação custo/benefício
5. Discussão
Nesse artigo alguns pontos a respeito da elasticidade foram discutidos e chegou-se a
quatro pontos fundamentais: escolha da métrica, escolha dos limiares, viabilidade de
uso de cloudburst e escolha da instância no provedor de nuvem pública. Embora
provedores nuvem pública ofereçam serviços com elasticidade e métricas para o seu
gerenciamento, não há conhecimento gerado e informações disponíveis sobre como
escolher métricas e configurar limiares. Estes aspectos desempenham um papel
importante no desempenho e no custo da computação em nuvem. O serviço
CloudWatch da Amazon oferece utilização de memória e CPU como métricas principais
mas também oferece a possibilidade de capturar métricas de aplicação. Seguindo essa
linha, este trabalho foi iniciado fazendo elasticidade com memória e com CPU, mas os
resultados foram muito insatisfatórios porque muito instabilidade era gerada. Uma
métrica de aplicação, o número de requisições, apresenta resultados positivos e com boa
relação com tempo de resposta (métrica relevante para o usuário).
Após a escolha da métrica, devem ser escolhidos valores de limiares positivos e
negativos para aumentar ou diminuir os recursos alocados. Os resultados evidenciam
que a qualidade para o cliente e o custo são muito sensíveis aos limiares. Fica evidente
que economizar utilizando limiares positivos e negativos altos esbarram num limite
onde passa a não mais valer a pena. A análise da métrica de busto/benefício mostra
claramente essa questão.
A avaliação da técnica de cloudburst mostra que é possível utilizá-la como
complemento para recursos da rede privada, que pode não possuir níveis médios de
ociosidade de recursos compatíveis com as demandas de todos os seus usuários. Quando
77
Anais do XII Workshop de Computação em Clouds e Aplicações - WCGA 2014
se utiliza cloudburst, a escolha do tipo da instância na nuvem pública tem grande
impacto na manutenção da qualidade e redução de custos. Por exemplo, a avaliação
mostrou que o uso de instâncias small da Amazon prejudica muito o desempenho da
aplicação avaliada. Por outro lado, instâncias large agregam pouco ao desempenho das
instâncias médium mas com um custo significativamente maior. Ressalta-se que essa
relação de desempenho de instâncias small, medium e large pode ser diferente para
aplicações com características diferentes.
6. Conclusão
O gerenciamento correto da elasticidade é fundamental para que usuários
obtenham o benefício da computação como utilidade num ambiente de nuvem. Pela
pouca discussão que existe na literatura, fica claro que os usuários não tem informações
precisas para lhes orientar na configuração de métricas e limiares para criar novos
recursos para atender a demanda e liberá-los quando não mais são necessários. Os
resultados mostram que a escolha de métricas e limiares é fundamental na manutenção
da qualidade aliada ao controle de custos. Foi usada uma métrica de aplicação, o
número de requisições, que trouxe estabilidade no gerenciamento da elasticidade. Ficou
claro também que o uso de limiares muito altos ou baixos distorce a relação
custo/benefício. Além disso, cloudburst pode ser usado para implementar uma nuvem
híbrida mas a escolha do tipo de máquina virtual tem impacto significativo.
Como trabalhos futuros, serão realizados novos experimentos com padrões
diferentes de envio de requisições pelos clientes. Serão também realizados estudos sobre
o uso de técnicas estatísticas ou histerese para gerenciar o momento da realização da
elasticidade positiva ou negativa.
Referências
Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz, R., Konwinski, A., Lee, G.,
Patterson, D., Rabkin, A., Stoica, I., Zaharia, M., (2010). “A View of Cloud
Computing”, Communications of the ACM, 53(4), p. 50-58, Abril de 2010.
Calcavecchia, N., Caprarescu, B., Di Nitto, E., Dubois, D., and Petcu, D. (2012).
DEPAS: a decentralized probabilistic algorithm for auto-scaling. Computing,
94:701–730.
Galante, G.; de Bona, L.C.E., (2012). "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.
Ipakchi, A., Albuyeh, F. (2009), “Grid of the Future: Are We Ready to Transition to a
Smart Grid?”, IEEE Power & Energy Magazine, 7(2), p. 52-62, Março 2009.
Leymann, F. (2009). “Cloud Computing: The Next Revolution in IT,” in Proc. 52th
Photogrammetric Week. W. Verlag, , pp. 3–12 Setembro de 2009.
Morais, F. et. al (2013). “Um Arcabouço para Provisionamento Automático de Recursos
em Provedores de IaaS Independente do Tipo de Aplicação”, SBRC 2013, Maio.
Mell, P. and Grance, T. (2011). “The NIST Definition of Cloud Computing,” US Nat’l
Inst. of Science and Technology, 2011.
Seung, Y., Lam, T., Li, L. E., Woo, T. (2011). Cloudflex: Seamless scaling of enterprise
applications into the cloud. INFOCOM, páginas 211–215.
78