MARÍA ELENA VILLARREAL
NETPOWERCLOUDSIM: EXTENSÃO DO CLOUDSIM PARA VALIDAÇÃO DE UM
MODELO DE GERENCIAMENTO DE EQUIPAMENTOS DE REDE LEGADOS EM
NUVEM VERDE
Rio do Sul
2013
MARÍA ELENA VILLARREAL
NETPOWERCLOUDSIM: EXTENSÃO DO CLOUDSIM PARA VALIDAÇÃO DE UM
MODELO DE GERENCIAMENTO DE EQUIPAMENTOS DE REDE LEGADOS EM
NUVEM VERDE
Trabalho de Curso apresentado ao curso de
graduação em Ciência da Computação do
Instituto Federal de Educação, Ciência e
Tecnologia Catarinense – Campus Rio do Sul
para a obtenção do título de Bacharel em
Ciência da Computação.
Orientador: Prof. Rodrigo Curvêllo, Msc
Rio do Sul
2013
MARÍA ELENA VILLARREAL
NETPOWERCLOUDSIM: EXTENSÃO DO CLOUDSIM PARA VALIDAÇÃO DE UM
MODELO DE GERENCIAMENTO DE EQUIPAMENTOS DE REDE LEGADOS EM
NUVEM VERDE
Este Trabalho de Curso foi julgado adequado
para a obtenção do título de Bacharel em
Ciência da Computação e aprovado em sua
forma final pelo curso de Ciência da
Computação do Instituto Federal de Educação,
Ciência e Tecnologia Catarinense – Campus
Rio do Sul.
_________________________, ______de_______________de 20_____.
_________________________________________________
Prof. Rodrigo Curvêllo, Msc (Orientador)
Instituto Federal Catarinense – Campus Rio do Sul
_________________________________________________
Prof. Tiago Boechel, Msc
Instituto Federal Catarinense – Campus Rio do Sul
_________________________________________________
Prof. Paulo César Rodacki Gomes, Dr
Instituto Federal Catarinense – Campus Blumenau
AGRADECIMENTOS
A Deus.
À minha família pelo apoio e incentivo.
Ao meu orientador , Rodrigo Curvêllo, pelo auxílio no desenvolvimento deste
trabalho.
RESUMO
A Computação em Nuvem é um paradigma que fornece infraestrutura, plataforma de
desenvolvimento e aplicativos como serviço, sob demanda e cobrados conforme a medição de
uso. Na prática, a Nuvem é implementada em datacenters, onde se concentram servidores
físicos que executam máquinas virtuais através das quais são prestados os serviços de
computação. A abordagem de Nuvem Verde incrementa o modelo com a proposta de reduzir
o consumo elétrico sem prejudicar a qualidade de serviço, mediante a concentração da carga
de trabalho na menor quantidade possível de equipamentos e desligando ou colocando em
estado de baixo consumo de energia os equipamentos ociosos. Simuladores são utilizados
para validar os algoritmos e estratégias de gerenciamento de nuvem verde. Este trabalho teve
como principal objetivo estender o CloudSim, um simulador de código aberto de ambientes
computacionais em nuvem, para que suporte a realização dos testes necessários para a
validação de um modelo de gerenciamento de equipamentos de rede legados em nuvem verde.
A metodologia utilizada consistiu em pesquisa bibliográfica, levantamento dos requisitos
funcionais e não funcionais, projeto e implementação das extensões em linguagem Java e
validação mediante testes e experimentos. Foram desenvolvidas classes que incorporam ao
CloudSim a capacidade de representar os equipamentos da rede e a sua topologia e uma classe
para gerenciá-los conforme as mudanças de estado dos servidores físicos. As extensões foram
validadas através de testes e da comparação dos resultados de simulações em diferentes
cenários, que demonstraram seu correto funcionamento.
Palavras-chave: Computação em Nuvem. Nuvem Verde. Simulação. CloudSim. Datacenter.
Gerenciamento de rede.
LISTA DE FIGURAS
Figura 1 – Camadas da implementação de uma nuvem. ......................................................... 19
Figura 2 – Arquitetura de nuvem verde e seus componentes. ................................................. 20
Figura 3 – Políticas de alocação: (a) Espaço compartilhado para MVs e tarefas, (b) Espaço
compartilhado para MVs e tempo compartilhado para tarefas, (c) Tempo compartilhado para
MVs e espaço compartilhado para tarefas, (d) Tempo compartilhado para MVs e tarefas. .... 27
Figura 4 – Diagrama de sequência do processamento de aplicações. ..................................... 29
Figura 5 – Diagrama de sequência da comunicação entre entidades. ..................................... 30
Figura 6 – Arquitetura de camadas do CloudSim. .................................................................. 31
Figura 7 – Diagrama de classes UML do CloudSim. .............................................................. 34
Figura 8 – Diagrama de classes UML do núcleo do CloudSim. ............................................. 35
Figura 9 – Topologia de rede padrão de um datacenter. ......................................................... 37
Figura 10 – Diagrama de casos de uso da interação do usuário com o simulador. ................. 42
Figura 11 – Diagrama de casos de uso da interação da interação do CloudSim com as
extensões................................................................................................................................... 43
Figura 12 – Diagrama de classes do NetPowerCloudSim. ...................................................... 44
Figura 13 – Diagrama de sequência da aplicação principal. ................................................... 45
Figura 14 – Diagrama de atividades do processo de reconfiguração da rede. ........................ 46
Figura 15 – Tela principal do NetPowerCloudSim. ................................................................ 54
Figura 16 – Resultados dos testes de unidade da classe TopologiaRede. ............................... 56
Figura 17 – Gráfico da evolução do consumo da rede no Experimento 2. ............................. 60
Figura 18 – Gráfico da evolução do consumo da rede no Experimento 3. ............................. 62
LISTA DE QUADROS
Quadro 1 – Requisitos funcionais. .......................................................................................... 41
Quadro 2 – Requisitos não funcionais..................................................................................... 41
Quadro 3 – Código do método que calcula a energia consumida por um switch durante um
frame da simulação. .................................................................................................................. 48
Quadro 4 – Trecho de código para atualizar o consumo atual do switch................................ 49
Quadro 5 – Trecho de código do método verificaMudancaEstadoHost. ................................ 50
Quadro 6 – Trecho do método que calcula as quantidades de racks, de switches de acesso, de
switches de agregação, de switches de núcleo e de módulos por switch de núcleo. ................ 51
Quadro 7 – Código do método que calcula os ids dos switches de acesso e o número das
portas aos quais uma máquina física está conectada. ............................................................... 52
Quadro 8 – Trecho de código do método desligaPortasSemUso que desliga as portas sem uso
dos dois últimos switches de acesso. ........................................................................................ 52
Quadro 9 – Código gerado pelo JUnit para teste do método calculaSwitchAcessoEporta e
adaptado com id de máquina física e resultados esperados. ..................................................... 55
Quadro 10 – Resultados do Experimento 1. ............................................................................ 58
Quadro 11 – Resultados do Experimento 2. ............................................................................ 59
Quadro 12 – Resultados do Experimento 3. ............................................................................ 61
Quadro 13 – Detalhamento do caso de uso UC01. ................................................................. 68
Quadro 14 – Detalhamento do caso de uso UC02. ................................................................. 68
Quadro 15 – Detalhamento do caso de uso UC03. ................................................................. 69
Quadro 16 – Detalhamento do caso de uso UC04. ................................................................. 70
Quadro 17 – Detalhamento do caso de uso UC05. ................................................................. 70
Quadro 18 – Detalhamento do caso de uso UC06. ................................................................. 71
Quadro 19 – Detalhamento do caso de uso UC07. ................................................................. 71
Quadro 20 – Detalhamento do caso de uso UC08. ................................................................. 72
Quadro 21 – Detalhamento do caso de uso UC09. ................................................................. 72
Quadro 22 – Detalhamento do caso de uso UC10. ................................................................. 73
Quadro 23 – Detalhamento do caso de uso UC11. ................................................................. 74
Quadro 24 – Detalhamento do caso de uso UC12. ................................................................. 75
Quadro 25 – Detalhamento do caso de uso UC13. ................................................................. 76
Quadro 26 – Detalhamento do caso de uso UC14. ................................................................. 76
LISTA DE SIGLAS
BRITE – Boston university Representative Internet Topology gEnerator
CIS – Cloud Information Service
CM – Cloud Manager
CPU – Central Processing Unit
EC2 – Elastic Compute Cloud
IaaS – Infrastructure as a Service
LAN – Local Access Network
MF – Máquina Física
MV – Máquina Virtual
NIST – National Institute of Standards and Technology
OTM – Organization Theory Model
PaaS – Platform as a Service
PE – Processing Element
QoS – Quality of Service
RAM – Random Access Memory
SaaS – Software as a Service
SLA – Service Level Agreement
UML – Unified Modeling Language
VIM – Virtual Infrastructure Manager
VMM – Virtual Machine Manager
SUMÁRIO
1 INTRODUÇÃO ................................................................................................................... 10
1.1 PROBLEMA ...................................................................................................................... 11
1.2 OBJETIVOS ....................................................................................................................... 12
1.2.1 Objetivo Geral................................................................................................................ 12
1.2.2 Objetivos Específicos ..................................................................................................... 12
1.3 JUSTIFICATIVA ............................................................................................................... 12
1.4 METODOLOGIA ............................................................................................................... 13
2 FUNDAMENTAÇÃO TEÓRICA ...................................................................................... 14
2.1 COMPUTAÇÃO EM NUVEM.......................................................................................... 14
2.1.1 Características da abordagem de nuvem .................................................................... 15
2.1.2 Modelos de serviços ....................................................................................................... 16
2.1.3 Modelos de implantação ................................................................................................ 17
2.1.4 Implementação de uma nuvem ..................................................................................... 17
2.1.5 Computação em Nuvem Verde ..................................................................................... 19
2.2 SIMULAÇÃO .................................................................................................................... 21
2.2.1 Conceitos relacionados .................................................................................................. 21
2.2.2 Vantagens e desvantagens ............................................................................................. 23
2.3 CLOUDSIM ....................................................................................................................... 25
2.3.1 Funcionamento do CloudSim ....................................................................................... 26
2.3.1.1 Modelagem da nuvem .................................................................................................. 26
2.3.1.2 Modelagem da alocação de máquinas virtuais ............................................................. 27
2.3.1.3 Modelagem do comportamento da rede ....................................................................... 27
2.3.1.4 Modelagem de cargas de trabalho dinâmicas ............................................................... 28
2.3.1.5 Modelagem do consumo de energia do datacenter ...................................................... 28
2.3.1.7 Processamento interno do datacenter ........................................................................... 29
2.3.1.8 Comunicação entre entidades ....................................................................................... 29
2.3.2 Arquitetura do CloudSim ............................................................................................. 30
2.3.3 Estrutura do CloudSim ................................................................................................. 31
2.4 TRABALHOS CORRELATOS ......................................................................................... 36
2.4.1 Modelos de Gerenciamento de Nuvem Verde ............................................................. 36
2.4.2 TeachCloud .................................................................................................................... 38
2.4.3 CloudReports ................................................................................................................. 38
2.4.4 NetworkCloudSim ......................................................................................................... 39
3 DESENVOLVIMENTO ...................................................................................................... 40
3.1 DESCRIÇÃO...................................................................................................................... 40
3.2 REQUISITOS ..................................................................................................................... 40
3.3 ESPECIFICAÇÃO ............................................................................................................. 41
3.3.1 Casos de Uso ................................................................................................................... 42
3.3.2 Diagrama de Classes ...................................................................................................... 44
3.3.3 Diagrama de Sequência ................................................................................................. 45
3.3.4 Diagrama de Atividades ................................................................................................ 45
3.4 IMPLEMENTAÇÃO.......................................................................................................... 47
3.4.1 Técnicas e ferramentas .................................................................................................. 47
3.4.2 Codificação das extensões ............................................................................................. 47
3.4.2.1 PowerSwitch ................................................................................................................. 48
3.4.2.2 NetPowerDatacenter ..................................................................................................... 49
3.4.2.3 TopologiaRede.............................................................................................................. 50
3.4.2.4 GerenciadorRede .......................................................................................................... 52
3.4.2.5 Classe principal e interface gráfica ............................................................................... 53
3.5 TESTES .............................................................................................................................. 54
3.5.1 Testes de Unidade .......................................................................................................... 54
3.5.2 Testes de Integração ...................................................................................................... 56
3.5.3 Validação de requisitos ................................................................................................. 57
3.6 SIMULAÇÕES E RESULTADOS .................................................................................... 57
3.6.1 Experimento 1 ................................................................................................................ 57
3.6.2 Experimento 2 ................................................................................................................ 58
3.6.3 Experimento 3 ................................................................................................................ 60
4 CONCLUSÕES .................................................................................................................... 63
REFERÊNCIAS...................................................................................................................... 65
APÊNDICE A – Detalhamento dos Casos de Uso ............................................................... 68
10
1 INTRODUÇÃO
Com a crescente preocupação por sustentabilidade e, consequentemente, pelo
consumo consciente de energia, o conceito de Green Cloud, ou Nuvem Verde, tem ganhado
destaque na comunidade científica. Esta abordagem une os conceitos de Computação em
Nuvem (Cloud Computing) e TI Verde (Green IT) com o intuito de “oferecer um ambiente
computacional flexível e eficiente” (WESTPHALL, VILLARREAL, 2013, p. 1).
De acordo com Geronimo (2012), o modelo de computação em nuvem verde visa,
além da economia de consumo energético, a redução de custos operacionais e o
prolongamento da vida útil de equipamentos em ambientes computacionais em nuvem.
Refere-se, portanto, à “utilização consciente e sustentável da tecnologia de Cloud Computing”
(GERONIMO, 2012, p. 39). Esta, por sua vez, pode ser definida como uma categoria de
serviços computacionais sofisticados oferecidos sob demanda através da Internet em que a
infraestrutura computacional é vista como uma “nuvem” e cujo princípio central é prover
computação, armazenamento e software “as a service” 1 (VOORSLUYS; BROBERG;
BUYYA, 2011, p. 3).
Na prática, segundo Westphall e Villarreal (2013), a nuvem é implementada em
datacenters, que concentram grande quantidade de máquinas físicas sobre as quais são
executadas as máquinas virtuais que são fornecidas aos clientes. Na computação em nuvem
verde, utiliza-se o conceito de consolidação de carga, que consiste em alocar a carga de
trabalho na menor quantidade possível de máquinas físicas para permitir desligar os recursos
ociosos ou colocá-los em estado de baixo consumo de energia elétrica (WESTPHALL;
VILLARREAL, 2013).
No entanto, segundo Villarreal e Westphall (2013), as estratégias de
gerenciamento de Nuvem Verde não têm dado suficiente atenção ao consumo dos
equipamentos de rede e à consolidação do tráfego e propuseram um modelo para o
gerenciamento dos recursos de rede dos datacenters, tanto os legados quanto os de tecnologia
verde.
Segundo Calheiros et al. (2011), diversos tipos de serviços podem ser oferecidos
em ambientes computacionais em nuvem e cada um possui diferentes exigências de
composição, configuração e implantação. Assim, a realização de testes em ambientes reais
para avaliar o desempenho destes serviços sob condições variáveis, frequentemente, não é
uma tarefa viável, visto que demanda muito tempo e é limitada pela rigidez física da estrutura.
1
Tradução: como um serviço.
11
As ferramentas de simulação, por outro lado, facilitam a reprodução de resultados ao
permitirem testar distintos cenários em ambientes repetíveis e controláveis antes da
implantação dos serviços em infraestruturas reais (CALHEIROS et al., 2011).
O CloudSim é um framework 2 que permite modelar e simular ambientes
computacionais em nuvem. De acordo com Calheiros et al. (2011), este conjunto de
ferramentas foi desenvolvido na linguagem de programação Java e suporta a simulação de
componentes de ambientes em nuvem como datacenters, máquinas virtuais e políticas de
provisionamento de recursos. O simulador permite ainda que seus recursos sejam estendidos,
o que possibilita a modelagem de ambientes de computação em nuvem personalizados e a
realização de testes baseados em cenários e configurações específicos para atender a uma
determinada pesquisa (CALHEIROS et al., 2011).
Neste trabalho, são realizadas extensões ao simulador CloudSim para permitir a
validação do modelo de gerenciamento de equipamentos de redes citado anteriormente. Nas
seções seguintes são descritos o problema, os objetivos, a justificativa e a metodologia. No
capítulo 2, é apresentada a fundamentação teórica, que aborda os conceitos de Computação
em Nuvem e Nuvem Verde, o processo de simulação, a estrutura e o funcionamento do
CloudSim e os trabalhos correlatos. No capítulo 3, é relatado o desenvolvimento das
extensões, incluindo os requisitos funcionais e não funcionais; a especificação da
implementação; os testes realizados; as simulações executadas e os resultados obtidos. Por
fim, no capítulo 4, são feitas as considerações finais e propostas de trabalhos futuros.
1.1 PROBLEMA
Villarreal e Westphall (2013) propuseram uma ampliação a uma abordagem de
alocação e distribuição de máquinas virtuais em ambiente de nuvem computacional verde.
Esta abordagem, baseada no modelo de Teoria da Organização, foi desenvolvida pelo
Laboratório de Redes e Gerência (LRG) da Universidade Federal de Santa Catarina e
apresentada e validada por Werner (2011). A extensão proposta incorpora estratégias de
eficiência energética ao modelo mediante o acréscimo de mecanismos para o gerenciamento
de recursos de rede de datacenters, tanto os legados quanto os de tecnologia verde
(VILLARREAL; WESTPHALL, 2013).
2
Aplicação parcialmente completa e reutilizável que pode ser adaptada para o desenvolvimento de aplicações
personalizadas (FAYAD; SCHMIDT, 1997).
12
No entanto, para medir os ganhos de eficiência obtidos com a otimização do
consumo dos equipamentos de rede e validar o modelo ampliado, é necessário estender o
simulador CloudSim, que não possui capacidade para representar os equipamentos e a
topologia da rede e realizar seu gerenciamento, recursos necessários para os testes que devem
ser realizados a fim de verificar os efeitos do modelo proposto.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Este trabalho tem como objetivo estender o simulador CloudSim de forma que
permita a realização dos testes necessários para a validação de um modelo de gerenciamento
de equipamentos de rede legados em um ambiente computacional de nuvem verde.
1.2.2 Objetivos Específicos
Os objetivos específicos do trabalho são:
a) implementar classes para a representação de entidades de rede conforme
as necessidades do modelo e para a geração da topologia da rede a partir
de regras previamente definidas;
b) incluir as funcionalidades de ativação e desativação de equipamentos de
rede e portas em função da consolidação de carga dos servidores;
c) permitir a configuração da velocidade das portas dos equipamentos de
rede de acordo com as regras e crenças do modelo;
d) calcular o consumo de energia dos equipamentos de rede e da rede em
geral;
e) interagir com as classes já existentes no simulador;
f) integrar os resultados aos das classes do CloudSim.
1.3 JUSTIFICATIVA
Através do gerenciamento dos recursos de rede em ambientes de nuvem
computacional verde proposta por Villarreal e Westphall (2013), é possível diminuir o
consumo energético de equipamentos de rede e servidores e, por conseguinte, obter
significativos ganhos de eficiência em datacenters e reduzir o impacto ambiental. Para
13
mensurar e validar estes ganhos a fim de possibilitar a implantação do modelo em ambientes
reais, é necessário realizar simulações que permitam testar os efeitos da aplicação desta
abordagem “em diferentes cenários com diferentes exigências de desempenho e com
diferentes regras e crenças” (VILLARREAL; WESTPHALL, 2013, p. 11).
Estender o simulador CloudSim permitirá, além da validação do modelo
mencionado, a realização de simulações para oferecer suporte a pesquisas da área de
computação em nuvem verde realizadas pelo Laboratório de Redes e Gerência do
departamento de Ciência da Computação da Universidade Federal de Santa Catarina.
Além das contribuições ambientais e acadêmicas já citadas, as extensões
realizadas ao CloudSim em conjunto com sua devida documentação podem servir como base
para novas extensões, bem como para a criação de ferramentas completas de simulação
específicas para ambientes computacionais em nuvem verde.
1.4 METODOLOGIA
Para a elaboração deste trabalho, será realizada uma pesquisa bibliográfica em
livros, artigos científicos publicados e monografias acadêmicas acerca dos temas de
Computação em Nuvem e Computação em Nuvem Verde, bem como sobre os conceitos
básicos de simulação. Também serão estudados e descritos a estrutura e o funcionamento do
simulador CloudSim e trabalhos correlatos.
Serão definidos os requisitos funcionais e não funcionais que devem ser atendidos
pelas extensões e as classes a serem implementadas ou estendidas serão modeladas através de
Diagramas UML de Classes, de Casos de Uso, de Atividades e de Sequência. Visto que o
simulador CloudSim foi desenvolvido em Java, as extensões serão implementadas nesta
linguagem e o paradigma de programação a ser utilizado é a orientação a objetos.
Com o intuito de validar as extensões realizadas ao CloudSim, serão efetuados
testes e experimentos de acordo com as regras e crenças definidas no modelo de simulação da
abordagem proposta por Villarreal e Westphall (2013).
Uma vez verificado e comprovado o correto funcionamento das extensões
realizadas, estas serão documentadas com o auxílio do gerador de documentação Javadoc,
desenvolvido pela Sun Microsystems.
14
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo, é abordado o tema de Computação em Nuvem, através da
definição do paradigma e da descrição de suas características fundamentais, dos tipos de
serviços oferecidos e das formas de implantação. São descritas ainda a arquitetura e a
implementação de uma nuvem. Em relação ao processo de simulação, são definidos conceitos
básicos e relacionados, bem como seus aspectos positivos e negativos. Para o entendimento
do funcionamento e da estrutura do simulador CloudSim, são apresentadas suas características
e arquitetura, as principais classes de sua implementação e a forma como se relacionam.
2.1 COMPUTAÇÃO EM NUVEM
A Computação em Nuvem, do inglês Cloud Computing, apresenta diversas
definições na literatura. Com o intuito de conceituar o paradigma, duas delas são apresentadas
a seguir:
“Computação em nuvem é um modelo que permite acesso ubíquo, conveniente e
sob demanda através de uma rede a um conjunto compartilhado de recursos
computacionais configuráveis (como redes, servidores, armazenamento, aplicações e
serviços) que podem ser rapidamente provisionados e liberados com um esforço
mínimo de gestão ou de interação com o provedor de serviço” (MELL; GRANCE,
3
2011, p.2) .
“Uma nuvem é um tipo de sistema de computação paralelo e distribuído que
consiste em uma coleção de computadores virtualizados e interconectados que são
provisionados dinamicamente e apresentados como um ou mais recursos
computacionais unificados baseado em acordos de nível de serviço estabelecidos
através de negociação entre o provedor de serviços e o consumidor” (BUYYA;
4
YEO; VENUGOPAL, 2008, p. 2) .
Com base nestas definições, observa-se que a Computação em Nuvem abrange
tanto as aplicações que são fornecidas como serviço através da Internet quanto o hardware e o
software dos datacenters responsáveis pelo fornecimento de tais serviços (ARMBRUST et
al., 2010).
3
Texto original traduzido por esta autora: “Cloud computing is a model for enabling ubiquitous, convenient, ondemand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage,
applications, and services) that can be rapidly provisioned and released with minimal management effort or
service provider interaction”.
4
Texto original traduzido por esta autora: "A Cloud is a type of parallel and distributed system consisting of a
collection of inter-connected and virtualised computers that are dynamically provisioned and presented as one or
more unified computing resources based on service-level agreements established through negotiation between
the service provider and consumers”.
15
Em relação à origem do conceito, a Computação em nuvem é resultado da
evolução e integração de diferentes tecnologias, como computação em grade, processamento
paralelo, computação autônoma, virtualização e browsers. Já o termo surgiu em 2006 em uma
palestra sobre como era realizado o gerenciamento dos datacenters da Google, ministrada
pelo funcionário da empresa, Eric Schmidt, e ganhou maior destaque com o lançamento do
serviço EC2 (Elastic Cloud Computing) da Amazon no mesmo ano (TAURION, 2009).
2.1.1 Características da abordagem de nuvem
O NIST (National Institute of Standards and Technology) define cinco
características essenciais que devem ser contempladas por uma nuvem (MELL; GRANCE,
2011). São elas:

autoatendimento sob demanda: uma nuvem permite que seus usuários
utilizem seus serviços de forma automática e sob demanda, sem a
necessidade de interação com operadores humanos;

amplo acesso à rede: os recursos são fornecidos através da rede e
acessados por mecanismos padronizados, que permitem o uso por
plataformas heterogêneas;

agrupamento de recursos: os recursos computacionais (físicos e virtuais)
do provedor de serviços são agrupados de forma a atender dinamicamente
as demandas dos consumidores, que, na maior parte das vezes, não têm
conhecimento da localização exata de tais recursos, mas podem ser
capazes de determiná-la em um nível de abstração mais alto (como país,
estado ou datacenter);

rápida elasticidade: os recursos fornecidos através de uma nuvem podem
ser provisionados e liberados rapidamente para ajustarem-se à variação da
demanda. Como resultado, frequentemente, o usuário tem a impressão de
que os recursos oferecidos são ilimitados;

serviço medido: sistemas em nuvem controlam e otimizam o uso dos
recursos automaticamente através de medições e podem monitorar e
reportar a utilização de recursos de forma transparente aos consumidores e
provedores.
Para que uma nuvem atenda às expectativas dos consumidores, Voorsluys,
Broberg e Buyya (2011) definem ainda como atributos indispensáveis:
16

medição e cobrança por uso: os recursos oferecidos por uma nuvem devem
ser medidos de acordo com o tipo de serviço e cobrados conforme o uso;

customização: como há grandes disparidades entre as necessidades dos
usuários, os serviços da nuvem devem ser altamente personalizáveis.
2.1.2 Modelos de serviços
Os serviços oferecidos em um ambiente computacional em nuvem são divididos
em três modelos ou níveis de abstração, que podem ser vistos como uma arquitetura de
camadas na qual os serviços de uma camada mais baixa compõem serviços de uma camada
mais alta (VOORSLUYS; BROBERG; BUYYA, 2011).
Os modelos de serviços são descritos a seguir:

Infraestrutura como Serviço (IaaS – Infrastructure as a Service): de
acordo com Voorsluys, Broberg e Buyya (2011), é considerada a camada
inferior dos sistemas computacionais em nuvem e oferece recursos
virtualizados de servidores de computação, armazenamento e comunicação
sob demanda. Como exemplo deste modelo de serviço, pode-se citar o
EC2 da Amazon Web Services, que permite aos usuários utilizar
servidores virtuais e configurar e escalonar a capacidade do ambiente
computacional (AMAZON, 2013);

Plataforma como Serviço (PaaS – Platform as a Service): esta camada,
com nível de abstração intermediário, oferece um ambiente de
desenvolvimento e hospedagem que permite aos usuários criar aplicações
sem preocupar-se com requisitos de infraestrutura, como quantidade de
processadores ou memória necessários (VOORSLUYS; BROBERG;
BUYYA, 2011). É exemplo deste tipo de serviço o Windows Azure, da
Microsoft, que possibilita criar, implantar e gerenciar aplicativos através
de uma rede global de datacenters (MICROSOFT, 2013);

Software como Serviço (SaaS – Software as a Service): é a camada
superior da arquitetura, na qual os serviços oferecidos consistem em
aplicações que podem ser acessadas pelos usuários finais através da Web,
sem a necessidade de instalá-las localmente e com as mesmas
funcionalidades de programas tradicionais para desktop (VOORSLUYS;
BROBERG; BUYYA, 2011). Assim, de acordo com Mell e Grance (2011,
17
p. 2), o serviço fornecido ao consumidor é o uso de aplicações do provedor
que executam em uma infraestrutura de nuvem. O Google Apps constitui
um exemplo deste modelo, uma vez que oferece como serviço aplicativos
de e-mail, agenda, criação e compartilhamento de documentos, entre
outros (GOOGLE, 2013).
2.1.3 Modelos de implantação
Com base nas formas de implantação e acesso, e a despeito do modelo de serviço
oferecido, uma nuvem pode ser classificada como:

pública: modelo de nuvem disponibilizado por organizações empresariais,
acadêmicas ou governamentais para o público em geral (MELL;
GRANCE, 2011). De acordo com Sun Microsystems (2009), este tipo de
nuvem permite que empresas utilizem infraestruturas muito maiores do
que as que poderiam possuir e transfere os riscos destas para o provedor de
serviços;

privada: neste modelo, a infraestrutura da nuvem pode ser utilizada apenas
por membros de uma determinada organização. No entanto, pode ser
gerenciada pela própria organização ou por terceiros (MELL; GRANCE,
2011);

comunitária: é compartilhada por um grupo de consumidores de
organizações distintas, mas com objetivos ou políticas em comum e pode
ser gerenciada e operada por uma ou mais organizações pertencentes à
comunidade ou por terceiros (MELL; GRANCE, 2011);

híbrida: uma nuvem híbrida, segundo Mell e Grance (2011), é composta
por dois ou mais tipos diferentes de nuvens (pública, privada ou
comunitária), que, apesar de unidas por tecnologias proprietárias ou
padronizadas, permanecem como entidades únicas.
2.1.4 Implementação de uma nuvem
De acordo com Taurion (2009, p.44), “o fundamento básico da Computação em
Nuvem é a virtualização dos recursos computacionais” e, para que esta virtualização seja
18
possível, são empregadas distintas tecnologias, que formam uma estrutura de camadas. Esta
estrutura e seus componentes são mostrados na Figura 1.
A camada mais baixa compreende as Máquinas Físicas (MFs), que compõem o
datacenter e consistem em servidores de computação e armazenamento que fornecem a
infraestrutura de hardware para criar recursos virtualizados (BUYYA; BELOGLAZOV;
ABAWAJY, 2010).
A segunda camada contém o software de virtualização, denominado VMM
(Virtual Machine Manager), que executa em cada servidor físico e tem como função
instanciar as Máquinas Virtuais (MVs) que são fornecidas aos consumidores (CELESTI et al.,
2013). Segundo Chaves, Uriarte e Westphall (2011) o VMM, também chamado de monitor,
permite executar o sistema operacional hóspede em cada máquina virtual e fornece a interface
entre os recursos virtuais e reais do sistema hospedeiro.
Na terceira camada, encontra-se o VIM (Virtual Infrastructure Manager), cuja
finalidade é o gerenciamento de recursos físicos e virtuais. Este middleware define quais MVs
serão instanciadas e em qual servidor físico e é responsável por configurá-las (CELESTI et
al., 2013). Voorsluys, Broberg e Buyya (2011) comparam o VIM a um sistema operacional
tradicional, com a diferença de que este agrega recursos de diferentes computadores e os
apresenta como um sistema uniforme a usuários e aplicações.
A última camada é constituída pelo CM (Cloud Manager), que age como a
interface entre os usuários e a infraestrutura, implementa a lógica de negócio do provedor e
aborda questões de segurança e QoS (Quality of Service) (CELESTI et al., 2013). Esta
camada é, portanto, responsável pelo Acordo de Nível de Serviço (SLA – Service Level
Agreement), que é o acordo legal firmado entre o provedor de serviços e o cliente a fim de
garantir a qualidade de serviço requerida. O SLA define uma lista de serviços e seus
respectivos atributos de qualidade, como tempo de resposta, disponibilidade, confiabilidade e
custo (MENASCE; ALMEIDA; DOWDY, 2004).
19
Figura 1 – Camadas da implementação de uma nuvem.
Fonte: Acervo do autor.
2.1.5 Computação em Nuvem Verde
A Computação em Nuvem Verde, do inglês Green Cloud Computing, visa o uso
eficiente da infraestrutura de computação em nuvem. Assim, difere da abordagem de nuvem
convencional, uma vez que leva em consideração a eficiência energética em datacenters,
cujos recursos devem ser alocados de forma que não apenas se cumpram os requisitos de QoS
definidos no SLA, mas também que seja possível reduzir o uso de energia elétrica (BUYYA;
BELOGLAZOV; ABAWAJY, 2010).
De acordo com Beloglazov et al. (2011, p. 11), “a principal causa de ineficiência
energética em datacenters é a baixa média de utilização dos recursos”5 ocasionada devido à
variabilidade da carga de trabalho, que obriga os datacenters a serem equipados para suprir
picos de carga que raramente acontecem na prática. Como consequência, os recursos
computacionais encontram-se subutilizados a maior parte do tempo e, nesta condição, a
eficiência energética das máquinas físicas é mínima. Estas afirmações estão baseadas na
constatação de que o consumo de energia do hardware não é proporcional à carga de trabalho.
Como descrito por Bose et al. (2011), ambientes de nuvem convencional utilizam
técnicas de balanceamento de carga, que distribuem igualmente as solicitações recebidas entre
um grupo de MFs. Dessa forma, os servidores operam com o mínimo possível de carga para
garantir alta performance e, consequentemente, atender às exigências de qualidade de serviço.
O modelo de nuvem verde, por outro lado, baseia-se na consolidação de carga, que consiste
5
Texto original traduzido por esta autora: “The main reason of the power inefficiency in data centers is low
average utilization of the resources”.
20
em agrupar a carga de trabalho no menor número possível de recursos físicos e desligar ou
colocar em modo de baixo consumo energético os recursos ociosos a fim de reduzir o
consumo de energia elétrica sem violar o SLA (BUYYA; BELOGLAZOV; ABAWAJY,
2010). Portanto, segundo Werner et al. (2012, p. 1), o desafio em nuvem verde “é a operação
com o montante mínimo de recursos ativos, sem deixar de atender às exigências de qualidade
de serviço e de robustez”.
Em relação à arquitetura de uma nuvem verde, Buyya, Beloglazov e Abawajy
(2010) propõem um modelo composto por quatro entidades: os Consumidores ou os Brokers
que os representam, que solicitam o serviço da Nuvem; o Alocador de Serviço Verde, que
funciona como uma interface entre a infraestrutura da nuvem e os consumidores; as Máquinas
Virtuais, que podem ser dinamicamente ativadas ou desativadas em uma máquina física ou
migradas entre diferentes MFs a fim de consolidar a carga de trabalho; e as Máquinas Físicas.
Para que o Alocador de Serviço Verde possa gerenciar os recursos de forma eficiente
energeticamente, é necessária a interação entre alguns componentes, como o Monitor de
Energia, que observa e determina quais máquinas físicas devem ser ligadas ou desligadas; e o
Escalonador de Serviço, que atribui solicitações a MVs, determina direitos de recursos
alocados para MVs e decide quando adicionar ou remover MVs para atender à demanda. Este
modelo é demonstrado na Figura 2.
Figura 2 – Arquitetura de nuvem verde e seus componentes.
Fonte: Adaptado de BUYYA; BELOGLAZOV; ABAWAJY, 2010.
Como o desafio da Computação em Nuvem Verde é consolidar a carga de
trabalho sem violar o SLA, diferentes algoritmos e políticas de consolidação são propostos
21
por pesquisadores. Para validá-los, contudo, é essencial que sejam avaliados em
infraestruturas virtualizadas de grande escala. Logo, por ser extremamente complicado
conduzir experimentos em infraestruturas reais, simulações têm sido utilizadas como forma de
avaliar o desempenho de tais propostas, visto que possibilitam a realização de testes em
ambientes de larga escala e garantem que experimentos possam ser reproduzidos e repetidos
(BELOGLAZOV, 2013).
2.2 SIMULAÇÃO
A simulação, como definido por Shannon (1998, p. 1), é “o processo de projetar
um modelo de um sistema real e conduzir experimentos com este modelo a fim de entender o
comportamento do sistema e/ou avaliar diversas estratégias para o seu funcionamento” 6. A
simulação pode ser vista como uma metodologia experimental e aplicada que imita o
funcionamento de um processo ou sistema real ao longo do tempo (BANKS, 1999).
Simulações são utilizadas para, além de descrever e analisar o funcionamento de
um sistema, prever comportamentos futuros deste e responder questões do tipo “O que
aconteceria se?”, a fim de resolver problemas reais (Banks, 1999). De acordo com Carson
(2004), a avaliação, a comparação e a análise são os principais motivos para a realização de
simulações, enquanto que a predição do desempenho e a identificação de problemas do
sistema, bem como suas causas, constituem os principais resultados.
2.2.1 Conceitos relacionados
Há diversos termos e conceitos fundamentais envolvidos na modelagem e na
simulação de sistemas (BANKS, 1999). Os mais relevantes para este trabalho são descritos a
seguir:

sistema: consiste em um grupo ou coleção de elementos inter-relacionados
que cooperam entre si para atingir um determinado objetivo (SHANNON,
1998). Freitas Filho (2008, p. 25) define um sistema como “um grupo de
componentes que recebem estímulos ou entradas (inputs) e produzem
respostas ou saídas (outputs)”;
6
Texto original traduzido por esta autora: “the process of designing a model of a real system and conducting
experiments with this model for the purpose of understanding the behavior of the system and/or evaluating
various strategies for the operation of the system”.
22

modelo: é uma representação descritiva de um processo ou sistema real,
que geralmente apresenta parâmetros que o tornam configurável
(CARSON, 2004). O modelo deve ser projetado de forma que o seu
comportamento imite o comportamento de resposta do sistema real a
eventos que ocorrem ao longo do tempo (SHANNON, 1998) e deve ser
simples, porém o suficientemente complexo para responder as questões
levantadas (BANKS, 1999). Segundo Carson (2004), o excesso de
detalhes em um modelo pode conduzir o projeto ao fracasso;

estado do sistema: é uma lista de valores capazes de definir o sistema em
qualquer instante. Na prática, é definido implicitamente pelos status
internos de todas as entidades pertencentes à simulação (CARSON, 2004);

eventos: são acontecimentos que, de acordo com Carson (2004), mudam o
estado do sistema e podem ser classificados como primários (programados
para ocorrer em um momento futuro através de dados e suposições
estatísticas) e secundários (programados para ocorrer imediatamente
segundo a lógica interna do modelo);

entidade: representa um objeto real no modelo e pode ser dinâmica,
quando se move através do sistema; ou estática, quando serve a outras
entidades (BANKS, 1999). Tarefas que chegam e deixam a CPU (Central
Processing Unit) depois de processadas são exemplos de entidades
dinâmicas e a própria CPU, de entidade estática (FREITAS FILHO, 2008);

atributos: constituem características associadas a uma entidade específica,
como nome, prioridade ou tempo de processamento necessário
(SHANNON, 1998). Os atributos devem, portanto, ser considerados como
valores locais (BANKS, 1999);

variável de estado: é toda informação necessária para determinar o que
está acontecendo no sistema em um determinado momento (BANKS,
1999). Para que a execução de uma simulação interrompida possa ser
retomada do ponto em que foi parada, todas as variáveis de estado devem
ter seus valores conhecidos no momento da interrupção, uma vez que estes
representam o estado do sistema (FREITAS FILHO, 2008);

recurso: constitui uma entidade estática que fornece serviços a uma ou
mais entidades dinâmicas simultaneamente e pode apresentar diversos
23
estados. Os mais comuns são ocupado e ocioso, mas há outras
possibilidades, como falhado, bloqueado ou indisponível (BANKS, 1999);

tempo de atividade: período que corresponde a uma ação cuja duração é
predeterminada, ou seja, é conhecida antes do início da atividade. Esta
duração pode ser uma constante ou resultado de uma expressão
matemática (FREITAS FILHO, 2008);

tempo de espera ou delay: período que corresponde a uma ação cuja
duração é indefinida, pois depende de outros eventos. Logo, constitui o
oposto de uma atividade (BANKS, 1999);

processo: é uma sequência de eventos, atividades e tempos de espera
associados a uma entidade à medida que esta se move pelo sistema
(CARSON, 2004);

processamento de listas: corresponde à forma como uma fila de entidades
que estão aguardando os recursos solicitados é gerenciada. As filas são
representadas por listas ordenadas e a política de processamento mais
utilizada é a FIFO (First In, First Out), na qual o primeiro a chegar é o
primeiro a ser atendido (FREITAS FILHO, 2008);

modelo de simulação de eventos discretos: modelo no qual as variáveis de
estado são modificadas apenas em momentos definidos, ou seja,
permanecem inalteradas durante intervalos de tempo e mudam quando um
evento ocorre (BANKS, 1999);

modelo de simulação contínuo: modelo no qual as variáveis de estado são
modificadas continuamente ao longo do tempo (FREITAS FILHO, 2008);

simuladores: são softwares que realizam simulações e, muitas vezes,
contêm pacotes com modelos que necessitam apenas de dados de entrada
para funcionar (BANKS, 1999).
2.2.2 Vantagens e desvantagens
A simulação para a análise de sistemas apresenta diversas vantagens em
comparação com os modelos analíticos ou matemáticos e com a realização de testes em
ambientes reais (SHANNON, 1998). Os principais benefícios citados na literatura são
descritos a seguir:
24

a simulação permite avaliar, uma vez criado o modelo de simulação,
políticas e métodos de funcionamento sem as despesas e o transtorno de
realizar experimentos com o sistema real (BANKS, 1999);

simulações possibilitam a identificação de “gargalos” e, por conseguinte, a
descoberta das causas de demoras em diversos processos (BANKS, 1999);

através de simulações, é possível testar hipóteses sobre como ou por que
um determinado fenômeno ocorre no sistema (SHANNON, 1998);

o processo de simular permite controlar o tempo, comprimindo-o ou
expandindo-o de forma a acelerar ou retardar um fenômeno para que este
possa ser meticulosamente investigado (BANKS, 1999). Conforme
Shannon (1998), é possível simular meses ou anos de operação de um
sistema em questão de segundos, bem como desacelerar um fenômeno
momentâneo para estudá-lo;

estudos de simulação mostram como um sistema realmente opera, em vez
de indicar previsões sobre seu funcionamento realizadas por um indivíduo
(BANKS, 1999) e auxiliam na identificação das variáveis mais relevantes
para o seu desempenho (SHANNON, 1998);

simulações permitem estudar como um sistema se modifica ao longo do
tempo e como seus subsistemas e componentes interagem (CARSON,
2004);

o ato de simular possibilita entender por que um determinado fenômeno
ocorre, uma vez que permite ver e controlar o sistema em sua totalidade
(BANKS, 1999);

a simulação permite diagnosticar problemas através de modelos
complexos e, portanto, de alta fidelidade; bem como compreender seus
efeitos no sistema (BANKS, 1999);

normalmente, o custo de um estudo de simulação corresponde a menos de
1% do total gasto para a implementação de um sistema e é, portanto, um
investimento inteligente (BANKS, 1999);

um estudo de simulação permite testar todos os aspectos de um sistema
sem que seja necessário adquirir e implantar os recursos físicos (BANKS,
1999);
25

um modelo de simulação fornece o único método para estudar sistemas
dinâmicos complexos que ainda não foram implementados e para os quais
os modelos analíticos ou estáticos apresentam baixas fidelidade e acurácia
(CARSON, 2004);
Embora o processo de simulação seja uma excelente ferramenta de análise,
apresenta algumas desvantagens (FREITAS FILHO, 2008). Entre elas:

a criação de modelos exige treinamento especializado (BANKS, 1999);

como as saídas das simulações são, geralmente, variáveis aleatórias, seus
resultados podem ser difíceis de interpretar (BANKS, 1999). Em muitos
casos, é trabalhoso determinar se uma saída está associada a “alguma
relação significante no sistema ou a processos aleatórios construídos e
embutidos no modelo” (FREITAS FILHO, 2008, p. 27);

a modelagem e a análise de simulações podem consumir muitos recursos,
como tempo e capital (CARSON, 2004);

modelos de simulação não fornecem uma solução otimizada, mas uma
ferramenta de análise do comportamento de um sistema sob condições
específicas (SHANNON, 1998);

simulações podem ser usadas de forma inapropriada. Há situações em que
uma solução analítica, por exemplo, seria adequada ou até melhor
(BANKS, 1999).
2.3 CLOUDSIM
O CloudSim é uma ferramenta extensível de código aberto para simulação de
sistemas computacionais em nuvem desenvolvida na Universidade de Melbourne, na
Austrália. Este framework foi projetado especificamente para modelagem e simulação de
infraestruturas de computação em nuvem, visto que os simuladores então disponíveis eram
voltados à Computação em Grade (Grid Computing) e, portanto, não ofereciam suporte ao
isolamento das abstrações das camadas de serviços (SaaS, PaaS e IaaS) e à simulação de
ambientes virtualizados, nem ferramentas para a modelagem de datacenters com grandes
quantidades de servidores (CALHEIROS et al., 2011).
O simulador CloudSim, segundo Calheiros et al. (2011), oferece como principais
recursos: suporte à modelagem e simulação de ambientes computacionais em nuvem de
grande escala em um único computador e com baixo consumo de recursos computacionais;
26
plataforma autônoma para modelagem de nuvens, agentes de serviços e políticas de alocação;
mecanismo de virtualização, que auxilia na criação e no gerenciamento de múltiplos serviços
em um nó do datacenter; flexibilidade de troca entre diferentes políticas de alocação de
núcleos de processamento; e criação dinâmica de entidades.
A partir da versão 2.0, através de extensões, o CloudSim permite realizar
simulações que levam em consideração o consumo de energia elétrica (capacidade que não
era contemplada pelo núcleo do framework). Foi incorporada também a possibilidade de
simular aplicações com cargas de trabalho dinâmicas (BELOGLAZOV, 2013).
2.3.1 Funcionamento do CloudSim
Para dar sustento à realização das extensões e simulações propostas, nesta seção,
são explicados os métodos de modelagem de componentes, o processamento interno de
aplicações e o fluxo de comunicação entre entidades do CloudSim conforme descrito por
Calheiros et al. (2011).
2.3.1.1 Modelagem da nuvem
No CloudSim, uma entidade é uma instância de um componente. Este, por sua
vez, pode ser uma classe ou um conjunto de classes que representam um modelo.
Assim, na modelagem de uma nuvem, Datacenter é uma entidade que gerencia
máquinas físicas, às quais são atribuídas máquinas virtuais por meio de uma política de
alocação definida pelo provedor de Nuvem. As máquinas físicas, por sua vez, são
representadas pelo componente Host, que possui atributos como capacidade de
processamento, memória, armazenamento e política de alocação de núcleos de processamento
a máquinas virtuais.
A alocação de máquinas virtuais em uma nuvem refere-se ao processo de criar
instâncias destas em máquinas físicas que atendem aos requisitos de hardware, como número
de núcleos de processamento e quantidade de memória. Assim, cada componente Host
instancia um componente VmScheduler, que representa uma política de alocação de núcleos a
MVs (por espaço ou tempo compartilhado).
27
2.3.1.2 Modelagem da alocação de máquinas virtuais
A alocação de máquinas virtuais leva em consideração a capacidade de
processamento e a largura de banda disponíveis na máquina física, uma vez que as MVs,
apesar de executarem em contextos isolados, compartilham os núcleos de processamento e o
barramento de sistema.
No CloudSim, a alocação é realizada em dois níveis: na máquina física e na
máquina virtual. No primeiro, é especificada a quantidade de poder de processamento de cada
núcleo que será atribuído a cada MV. No segundo, cada tarefa recebe um valor fixo do poder
de processamento disponível na máquina virtual. Em ambos os níveis, são implementadas
duas políticas básicas de provisionamento: tempo compartilhado e espaço compartilhado. Na
Figura 3, são mostrados os quatro cenários possíveis para o uso de tais políticas. O simulador
permite também que políticas personalizadas sejam criadas por desenvolvedores por meio de
extensões às classes existentes.
Figura 3 – Políticas de alocação: (a) Espaço compartilhado para MVs e tarefas, (b) Espaço compartilhado para
MVs e tempo compartilhado para tarefas, (c) Tempo compartilhado para MVs e espaço compartilhado para
tarefas, (d) Tempo compartilhado para MVs e tarefas.
Fonte: Adaptado de CALHEIROS et al., 2011.
2.3.1.3 Modelagem do comportamento da rede
A inclusão da topologia de rede e seu comportamento no modelo é uma
consideração importante, uma vez que a latência das mensagens trocadas entre entidades da
nuvem afeta o desempenho geral das aplicações e pode ocasionar violações ao SLA.
28
No CloudSim, a latência do tráfego da rede é simulada através de informação
armazenada em uma matriz de latência m x n, em que cada posição eij representa o tempo de
transferência de uma mensagem da entidade i para a entidade j. Assim, um evento é
transmitido entre i e j pelo mecanismo de gerenciamento de eventos quando o tempo total da
simulação é igual ao tempo em que a mensagem foi enviada mais a latência de rede entre as
duas entidades.
A topologia da rede é armazenada em um arquivo BRITE (Boston university
Representative Internet Topology gEnerator). Este arquivo contém os nós da rede, que
representam entidades do CloudSim, como máquinas físicas e datacenters, e é lido pelo
simulador e utilizado para gerar a matriz de latência.
Mensagens enviadas entre entidades do CloudSim constituem eventos e são
processadas por um objeto NetworkTopology, que possui a informação sobre a topologia da
rede. Este objeto acrescenta o valor de latência ao evento e o transfere para o motor de
gerenciamento de eventos para processamento adicional.
2.3.1.4 Modelagem de cargas de trabalho dinâmicas
O CloudSim suporta a simulação de aplicações que apresentam comportamentos
dinâmicos em relação à carga de trabalho, à disponibilidade e à escalabilidade. Para tanto, é
necessário implementar um modelo de utilização, que define a demanda de processamento de
uma aplicação, ou utilizar um dos modelos já disponíveis no simulador.
O simulador permite também a modelagem e a simulação de violações ao SLA,
através de políticas que definem quando estas violações podem ocorrer; e da contagem do
número de violações e de recursos que foram requisitados, mas não alocados.
2.3.1.5 Modelagem do consumo de energia do datacenter
Ambientes de computação em nuvem, com sua infraestrutura e sistemas de
refrigeração, podem consumir grande quantidade de energia elétrica. No CloudSim, é possível
gerenciar tal consumo através do objeto PowerModel, que pode ser estendido para suportar a
definição e a simulação de diferentes modelos de consumo e técnicas de gerenciamento de
energia. O simulador permite ainda a criação de políticas de provisionamento e o cálculo da
energia total consumida por um sistema durante o período de simulação.
29
2.3.1.7 Processamento interno do datacenter
O processamento das aplicações é feito pelas máquinas virtuais, que monitoram e
atualizam seu progresso continuamente. Um evento interno é gerado para informar à entidade
Datacenter que uma aplicação será finalizada em breve. Assim, a cada passo da simulação,
esta entidade chama um método que faz com que todas as máquinas físicas atualizem os status
de suas máquinas virtuais e aciona outro método. Este, por sua vez, faz com que as máquinas
virtuais atualizem os status de suas aplicações ativas e retornem o tempo do próximo evento.
As máquinas físicas, então, enviam os menores tempos de finalização para o Datacenter. Estes
tempos são armazenados em uma fila, que é consultada pela entidade Datacenter após cada
processamento de evento. A Figura 4 exibe esta sequência de atualização do processamento
de aplicações.
Figura 4 – Diagrama de sequência do processamento de aplicações.
Fonte: Adaptado de CALHEIROS et al., 2011.
2.3.1.8 Comunicação entre entidades
O CloudSim é um simulador baseado em eventos e, portanto, as diferentes
entidades de um sistema simulado comunicam-se por meio do envio de eventos. O fluxo
30
básico desta comunicação, demonstrado na Figura 5, inicia-se com o registro da entidade
Datacenter no CIS (Cloud Information Service). Em seguida, quando uma aplicação é enviada
pelo usuário, o DatacenterBroker consulta o CIS para identificar os provedores de nuvem
cujas infraestruturas atendam aos requisitos de software, hardware e QoS desta. Quando
identificados, o DatacenterBroker negocia e realiza a implantação de máquinas virtuais, que
executarão a aplicação, em uma ou mais máquinas físicas de um Datacenter sugerido pelo
CIS. Depois de finalizada a execução das tarefas, as MVs são destruídas.
Figura 5 – Diagrama de sequência da comunicação entre entidades.
Fonte: Adaptado de CALHEIROS et al., 2011.
2.3.2 Arquitetura do CloudSim
O framework CloudSim possui uma arquitetura constituída por três camadas:

camada do núcleo do simulador: é a camada inferior, onde a simulação é
processada. Nesta camada, é realizado o controle da execução e das filas
de eventos;

camada de simulação do CloudSim: é a camada intermediária, que contém
as classes de entidades que compõem o ambiente de computação em
nuvem, como máquinas físicas, máquinas virtuais, datacenter e PE
(Processing Element), e estão distribuídas entre as subcamadas Estruturas
de Interface do Usuário, Serviços da Máquina Virtual, Serviços da Nuvem,
Recursos da Nuvem e Rede. Esta camada é ainda responsável pela
31
alocação de MVs a máquinas físicas, pelo gerenciamento da execução de
aplicativos e pelo monitoramento do estado do sistema dinâmico;

camada de usuário: é a camada superior da arquitetura, na qual é definido
o cenário da simulação através da configuração de entidades básicas, como
máquinas físicas (quantidade e suas especificações); aplicações (números
de tarefas e suas requisições); máquinas virtuais; número de usuários; tipos
de aplicações; e políticas de escalonamento.
A Figura 6 ilustra as três camadas do CloudSim e seus componentes.
Figura 6 – Arquitetura de camadas do CloudSim.
Fonte: CALHEIROS et al., 2011.
2.3.3 Estrutura do CloudSim
As principais classes que compõem o simulador, de acordo com Calheiros et al.
(2011), são descritas a seguir:

BwProvisioner:
classe
abstrata
que
representa
a
política
de
provisionamento de largura de banda a máquinas virtuais. Por padrão, é
estendida pela classe BwProvisionerSimple (que permite a uma máquina
virtual reservar a largura de banda necessária desde que esta quantidade
esteja disponível na máquina física), mas pode ser estendida por outras
32
classes criadas por pesquisadores e desenvolvedores para modelar novas
políticas que atendam às necessidades de determinadas aplicações;

Cloudlet: classe que modela as aplicações que executam na nuvem. Cada
aplicação possui um tamanho de instrução predeterminado e overhead de
transferência de dados e armazena informações como o id da máquina
virtual na qual é executada, o tamanho, o número de núcleos de
processamento requeridos para sua execução e seu status;

CloudletScheduler: classe abstrata que pode ser estendida de forma a
implementar diferentes políticas de compartilhamento do poder de
processamento de uma máquina virtual entre as aplicações que nela são
executadas. Duas classes que a estendem são oferecidas pelo CloudSim:
CloudletSchedulerSpaceShared
(espaço compartilhado)
e
Cloudlet-
SchedulerTimeShared (tempo compartilhado);

Datacenter: classe que modela a infraestrura oferecida como serviço pelos
provedores de computação em nuvem e consiste em um conjunto de
máquinas físicas com configurações de hardware (como memória,
quantidade de núcleos e capacidade de armazenamento) que podem ser
homogêneas ou heterogêneas;

DatacenterBroker: classe que modela um agente que opera em nome do
usuário e é responsável pela mediação das negociações entre ele e o
provedor de nuvem. Primeiro, o agente busca provedores de serviços
apropriados no CIS e, em seguida, realiza negociações de alocação de
recursos e serviços para atender aos requisitos de QoS. É possível estender
esta classe para a implementação de políticas de mediação personalizadas;

DatacenterCharacteristics: classe que contém as propriedades dos recursos
do datacenter, como arquitetura, sistema operacional, política de alocação,
VMM e custos;

Host: classe que modela um recurso físico (servidores de computação ou
armazenamento) e seus atributos, como quantidade de memória e
capacidade de armazenamento; política para o compartilhamento do poder
de processamento entre MVs; e políticas de provisionamento de memória
e largura de banda para MVs;
33

NetworkTopology:
classe
que
armazena
informações
sobre
o
comportamento da rede em uma simulação, através de matrizes de latência
e de largura de banda e sobre sua topologia, gerada a partir de um arquivo
BRITE;

RamProvisioner:
classe
abstrata
que
representa
a
política
de
provisionamento de memória RAM (Random Access Memory) a máquinas
virtuais e é responsável por verificar se o recurso físico possui memória
(livre) suficiente para a implantação e execução de determinada MV. É
estendida pela classe RamProvisionerSimple, que aloca a quantidade de
memória requisitada pela máquina virtual, exceto se esta for maior que a
memória disponível. Neste caso, o pedido é simplesmente rejeitado;

HarddriveStorage: classe que representa uma rede de armazenamento
composta por um conjunto de discos rígidos conectados através de uma
LAN (Local Access Network). Implementa uma interface que pode ser
utilizada para simular armazenamento e recuperação de qualquer
quantidade de dados, desde que a rede disponha da largura de banda
necessária;

Vm: classe que modela uma máquina virtual, gerenciada e hospedada por
uma máquina física. Possui características como número de processadores,
quantidade de memória RAM e política de alocação interna;

VmAllocationPolicy: classe abstrata que representa a política de alocação
de máquinas virtuais a máquinas físicas e tem como principal função
selecionar um recurso físico que atenda às exigências de memória,
armazenamento e disponibilidade para a implantação de uma MV. Este
processo é realizado em dois estágios: primeiro, a máquina física é
reservada e, depois da confirmação do usuário, a máquina virtual é
efetivamente alocada. A política padrão utilizada é implementada pela
classe VmAllocationPolicySimple e escolhe a máquina física com menor
número de PEs em uso para alocar uma máquina virtual;

VmScheduler:
classe
abstrata
que
representa
a
política
de
compartilhamento do poder de processamento entre as máquinas virtuais
que executam em uma mesma máquina física. Pode ser estendida para
suportar políticas específicas.
34
A Figura 7 apresenta as classes do CloudSim descritas anteriormente e as relações
entre elas.
Figura 7 – Diagrama de classes UML do CloudSim.
Fonte: Adaptado de CALHEIROS et al., 2011.
No núcleo da arquitetura, encontra-se o motor de simulação do CloudSim,
responsável pela criação e gerenciamento de eventos. As classes que compõem tal motor são
descritas a seguir:

CloudSim: classe principal, que é responsável por gerenciar filas de
eventos e controlar a execução destes passo a passo. Cada evento gerado
por esta entidade em tempo de execução é armazenado em uma fila de
eventos futuros, ordenada pelo atributo tempo. Quando o tempo de
simulação coincide com o tempo em que um evento está agendado para
ocorrer, este é transferido para a fila de eventos diferidos e um método de
processamento de eventos é chamado para realizar as ações necessárias;

DeferredQueue: classe que implementa a fila de eventos diferidos usada
pela entidade CloudSim;

FutureQueue: classe que implementa a fila de eventos futuros usada pela
entidade CloudSim;

CloudInformationService: classe que permite o registro de entidades e a
descoberta de recursos disponíveis de outras entidades;
35

SimEntity: classe abstrata que representa uma entidade da simulação capaz
de enviar mensagens a outras entidades; processar mensagens recebidas; e
disparar e manipular eventos;

CloudSimTags: classe que contém etiquetas de comando que indicam o
tipo de ação que deve realizada por entidades ao receberem ou enviarem
eventos;

SimEvent: classe que representa um evento enviado entre entidades e
possui atributos como tipo, tempo de inicialização, tempo em que o evento
deve ocorrer e tempo de finalização;

CloudSimShutdown: classe responsável por indicar o término de uma
simulação ao CIS;

Predicate: classe usada para determinar a seleção de eventos da fila de
eventos deferidos. É estendida pelas classes: PredicateAny (qualquer
evento da fila é selecionado); PredicateFrom (seleciona eventos disparados
por uma entidade específica); PredicateNone (não corresponde a nenhum
evento da fila); PredicateNotFrom (seleciona eventos que não foram
enviados por uma dada entidade); PredicateNotType (eventos que não
correspondem
a
determinados
marcadores
são
selecionados);
e
PredicateType (seleciona eventos com marcadores específicos).
A Figura 8 demonstra o diagrama de classes UML do núcleo de simulação do
CloudSim, formado por suas classes principais e pelos seus predicados.
Figura 8 – Diagrama de classes UML do núcleo do CloudSim.
Fonte: CALHEIROS et al., 2011.
36
2.4 TRABALHOS CORRELATOS
Nesta seção, são descritos os principais trabalhos relacionados a esta pesquisa. Os
dois primeiros consistem em modelos de gerenciamento para a redução do consumo de
energia elétrica em ambientes de nuvem verde e estão relacionados à motivação deste projeto.
Os demais referem-se a simuladores desenvolvidos a partir do CloudSim: TeachCloud,
CloudReports e NetworkCloudSim.
2.4.1 Modelos de Gerenciamento de Nuvem Verde
Werner (2011) propõe um modelo de alocação e distribuição de máquinas virtuais
como solução para o controle integrado de servidores e sistemas de suporte em nuvem verde.
Esta abordagem considera um sistema de gerenciamento com múltiplos componentes e é
baseada no OTM (Organization Theory Model), através do qual são definidos os padrões de
interação entre tais componentes e as regras de funcionamento.
Com base em normas, papéis, regras e crenças, este modelo prevê quando
máquinas virtuais devem ser desligadas, redimensionadas ou migradas e quando máquinas
físicas devem ser ligadas ou desligadas em função da carga de trabalho e das exigências do
SLA. A abordagem define ainda quando o desligamento ou o religamento dos sistemas de
suporte é necessário.
A proposta foi validada por meio de simulações de diferentes cenários e, segundo
Werner (2011), demonstrou ser eficiente, com uma economia de até 40% de energia elétrica
em comparação com o modelo de nuvem convencional.
Villarreal e Westphall (2013) realizaram extensões à proposta de Werner (2011) a
fim de acrescentar-lhe o gerenciamento dos equipamentos de rede legados, cujo consumo é
praticamente independente da carga de trabalho. O novo modelo visa tornar o consumo destes
equipamentos aproximadamente proporcional à carga e fazer com que a energia elétrica por
eles economizada contribua para a eficiência total do sistema.
Para a consolidação do tráfego da rede, foram elaboradas regras e crenças que
regem a correta configuração desta em função da consolidação de carga nos servidores. Os
autores desenvolveram ainda um modelo para gerar a topologia da rede do datacenter em
função do número de servidores físicos e definiram regras e fórmulas para calcular o consumo
dos switches e da rede completa.
37
O modelo proposto é baseado na topologia de rede padrão de um datacenter,
mostrada na Figura 9, que é composta por três camadas de switches: acesso, agregação e
núcleo. Nesta configuração, existe redundância nas conexões entre camadas e cada rack
acomoda até 40 máquinas físicas e dois switches de camada de acesso, sendo que cada MF
possui uma placa de rede conectada a cada switch de acesso do rack ao qual pertence.
Os autores consideram que cada switch de acesso possui 48 portas downlink, isto
é, portas para conexão com a camada imediatamente inferior, com velocidade Giga Ethernet e
2 portas uplink (para conexão com a camada superior) com velocidade 10 Giga Ethernet. Os
switches da camada de agregação, por sua vez, possuem 24 portas downlink 10 Giga Ethernet
e 2 portas uplink 40 Giga Ethernet. Já os switches de núcleo são compostos por módulos de
24 portas com velocidade 40 Giga Ethernet.
Assim, o modelo estabelece que até 12 racks podem ser atendidos por 2 switches
de camada de agregação; que, com menos de 12 racks, não são necessários switches de
camada de núcleo; e que até 144 racks podem ser atendidos por dois switches de camada de
núcleo com um módulo cada. Desta forma, é possível determinar a quantidade de cada tipo de
switch e suas interconexões a partir da quantidade de máquinas físicas.
Figura 9 – Topologia de rede padrão de um datacenter.
Fonte: Adaptada de VILLARREAL; WESTPHALL, 2013.
A economia energética proposta pelo sistema baseia-se no desligamento de portas,
módulos e switches inativos e na redução da velocidade de portas. O cálculo do consumo dos
switches é realizado através da soma do consumo base de cada tipo de switch com o
38
somatório dos consumos das portas. Este último depende da quantidade de portas ativas e da
velocidade configurada para cada porta.
Esta abordagem foi validada com um modelo analítico simples. No entanto, os
autores descrevem um modelo de simulação e sugerem como trabalhos futuros realizar
extensões ao simulador CloudSim para implementar tal modelo e executar experimentos a fim
de determinar tanto as regras mais eficientes quanto a contribuição e o impacto do modelo em
cenários com diferentes cargas de trabalho.
2.4.2 TeachCloud
O TeachCloud é uma ferramenta para modelagem e simulação de ambientes de
computação em nuvem voltada para o ensino e construída sobre a plataforma do CloudSim.
Entre os aprimoramentos e extensões introduzidas ao CloudSim pelo TeachCloud, pode-se
citar: interface gráfica para auxiliar os alunos a criarem os componentes de uma nuvem;
gerador de carga de trabalho Rain; módulos para a especificação de SLA; modelos de redes
para representar topologias existentes em ambientes de nuvem reais; monitoramento da maior
parte dos componentes de um sistema; e um módulo que permite aos estudantes reconfigurar
a nuvem e estudar o impacto das mudanças no desempenho do sistema (JARARWEH et al.,
2012).
O código do TeachCloud, segundo os autores, seria disponibilizado para
pesquisadores e estudantes. No entanto, o desenvolvimento foi descontinuado e todo o
conteúdo foi retirado do website do simulador7.
2.4.3 CloudReports
O CloudReports, desenvolvido na Universidade Federal do Ceará, é uma
ferramenta que utiliza o CloudSim como motor de simulação e provê atributos como:
interface gráfica, geração de relatórios e criação de extensões através de plugins que podem
ser conectados em tempo de execução sem a necessidade de recompilar o código fonte. No
entanto, o conjunto de extensões suportadas limita-se a apenas determinados tipos de
algoritmos, como: políticas de alocação de VMs e de provisionamento de recursos;
7
Endereço do website do TeachCloud: https://code.google.com/p/teachcloud/.
39
escalonadores de MVS e aplicações; e modelos de consumo de energia e modelos de
utilização (SÁ, 2013).
2.4.4 NetworkCloudSim
O NetworkCloudSim é um framework de simulação de ambientes de computação
em nuvem, cujos componentes foram implementados como parte do simulador CloudSim a
fim de dotá-lo de recursos para a modelagem do comportamento de aplicações e da rede
interna do datacenter. Foi desenvolvido por Garg e Buyya (2011) com o intuito de fornecer
um modelo escalável e generalizado de aplicação e de rede.
Para a modelagem de diferentes topologias de rede, o NetworkCloudSim
apresenta as classes: Switch, que representa uma entidade que pode ser configurada como um
roteador ou um switch e modela atrasos no encaminhamento de dados a outras entidades; e
NetworkPacket e HostPacket, que modelam, respectivamente, pacotes que viajam pela rede
virtual e pacotes que são transmitidos de um servidor a outro e, portanto, representam um
fluxo de dados entre MVs em um datacenter. Já para a modelagem de aplicações, foram
desenvolvidas as classes: NetworkCloudlet, que é uma extensão da classe Cloudlet do
CloudSim e representa uma tarefa generalizada com vários estágios; e AppCloudlet, que
representa uma aplicação com múltiplas tarefas (GARG; BUYYA, 2011).
O NetworkCloudSim, contudo, é voltado para a representação do tráfego da rede e
não suporta o gerenciamento e o cálculo do consumo elétrico dos equipamentos.
40
3 DESENVOLVIMENTO
Neste capítulo, é detalhado o desenvolvimento das extensões realizadas ao
simulador CloudSim. São relacionados os requisitos funcionais e não funcionais que devem
ser atendidos por tais extensões e é apresentada a especificação do projeto, através dos
diagramas de casos de uso, de classes, de sequência e de atividades. São descritos ainda a
implementação e o funcionamento das classes e dos algoritmos desenvolvidos, bem como os
testes realizados. Por fim, são demonstradas e discutidas as simulações executadas e os
resultados obtidos.
3.1 DESCRIÇÃO
As extensões desenvolvidas adicionam ao CloudSim a capacidade de definir uma
topologia de rede e representar e gerenciar seus componentes para realizar simulações que
consideram o consumo energético da rede do datacenter a fim de validar o sistema proposto
por Villarreal e Westphall (2013).
Este sistema, conforme descrito no capítulo 2, propõe extensões a um modelo de
gerenciamento de nuvem verde para gerenciar equipamentos de rede legados de forma a
tornar seu comportamento aproximadamente proporcional à carga de trabalho e baseia-se na
desconexão de portas, módulos e switches inativos e na redução da velocidade de portas. Os
autores propõem também um modelo de simulação baseado na topologia padrão de um
datacenter que, a partir da quantidade de máquinas físicas, determina os equipamentos de
rede necessários e suas interconexões e em uma fórmula para o cálculo do consumo dos
switches em função da quantidade de portas ativas e das velocidades das mesmas.
Desta forma, as extensões implementadas permitem simular e modelar a rede de
acordo com a topologia padrão definida, gerenciá-la conforme as regras estabelecidas no
modelo em função das mudanças de estados das máquinas físicas do datacenter e calcular a
energia consumida durante sua operação.
3.2 REQUISITOS
Os requisitos que devem ser atendidos pelas extensões ao CloudSim foram
levantados e revisados junto aos pesquisadores responsáveis pelo modelo de gerenciamento
mediante entrevistas e são especificados nos Quadros 1 e 2:
41
Quadro 1 – Requisitos funcionais.
REQUISITOS FUNCIONAIS
RF01: Permitir definir o cenário da simulação, incluindo características das máquinas
físicas, das máquinas virtuais, das aplicações e dos equipamentos de rede do datacenter.
RF02: Definir a topologia da rede a partir do número de máquinas físicas.
RF03: Representar os switches de acesso, agregação e núcleo e suas mudanças de estado.
RF04: Interagir com o CloudSim para que os eventos da simulação provoquem as mudanças
correspondentes no estado da rede.
RF05: Ligar e desligar equipamentos de rede e portas em função da consolidação de carga
das máquinas físicas.
RF06: Configurar a velocidade das portas dos equipamentos de rede em função da
utilização das máquinas físicas e da largura de banda agregada.
RF07: Calcular o consumo de energia elétrica dos equipamentos de rede.
RF08: Em cada passo da simulação, acrescentar o consumo da rede ao consumo total do
datacenter.
RF09: Permitir a realização de simulações sem gerenciamento da rede.
RF10: Informar as características da topologia e o consumo da rede em sua condição inicial.
RF11: Gerar e salvar registros (logs) das mudanças de estado da rede.
RF12: Salvar os resultados da simulação.
Quadro 2 – Requisitos não funcionais.
REQUISITOS NÃO FUNCIONAIS
RNF01: Executar em microcomputador convencional.
RNF02: Permitir simulações de 6 horas de operação de um datacenter com até 5.760
máquinas físicas com tempo de resposta menor que 1 hora.
RNF03: Permitir extensão para atender outras necessidades de pesquisas.
RNF04: Permitir fácil manutenção do código.
RNF05: Interface gráfica para definição do cenário da simulação e exibição dos resultados.
3.3 ESPECIFICAÇÃO
Para a especificação das extensões desenvolvidas, foram elaborados diagramas de
acordo com a linguagem de modelagem UML e com auxílio da ferramenta Astah Community.
Nesta seção, são apresentados os diagramas de casos de uso, de classes, de sequência e de
atividades.
42
3.3.1 Casos de Uso
Os casos de uso apresentados nesta seção, e detalhados no Apêndice A, estão
relacionados aos requisitos funcionais relatados na seção anterior e demonstram as interações
entre o sistema e os agentes externos. O primeiro diagrama, exibido na Figura 10, tem como
ator o usuário que deseja realizar simulações e compreende os casos de uso relacionados à
interação deste com o simulador através de uma interface gráfica.
No segundo diagrama, apresentado na Figura 11, o ator é o próprio simulador
CloudSim, que interage com as extensões desenvolvidas para reconfigurar a rede a cada
mudança de estado e calcular seu consumo.
Figura 10 – Diagrama de casos de uso da interação do usuário com o simulador.
43
Figura 11 – Diagrama de casos de uso da interação da interação do CloudSim com as extensões.
44
3.3.2 Diagrama de Classes
O diagrama de classes, mostrado na Figura 12, representa as classes
implementadas e as relações entre elas.
Figura 12 – Diagrama de classes do NetPowerCloudSim.
45
3.3.3 Diagrama de Sequência
O diagrama a seguir (Figura 13) mostra a sequência de criação dos objetos e as
chamadas de métodos necessários para executar uma simulação com o NetPowerCloudSim.
Figura 13 – Diagrama de sequência da aplicação principal.
3.3.4 Diagrama de Atividades
O diagrama UML apresentado na Figura 14 demonstra o fluxo de atividades do
processo de reconfiguração da rede, realizado pelo gerenciador de rede de acordo com a
mudança de estado de cada máquina física do datacenter em cada frame da simulação.
46
Figura 14 – Diagrama de atividades do processo de reconfiguração da rede.
47
3.4 IMPLEMENTAÇÃO
Nesta seção, são apresentadas as técnicas e as ferramentas utilizadas e é detalhada
a implementação das extensões realizadas ao simulador.
3.4.1 Técnicas e ferramentas
Para o desenvolvimento das extensões, foi utilizada a linguagem de programação
orientada a objetos Java e o ambiente de desenvolvimento Netbeans IDE 7.3.1, em conjunto
com o framework CloudSim 3.0.3 e a biblioteca gráfica Swing.
A fim de auxiliar na compreensão do código e do funcionamento dos algoritmos,
bem como facilitar futuras extensões, todas as classes criadas foram detalhadamente
comentadas, e foi gerada documentação com a ferramenta Javadoc, fornecida pela Sun
Microsystems.
Os testes de unidade realizados sobre as classes desenvolvidas foram criados com
auxílio do framework JUnit.
3.4.2 Codificação das extensões
Para a codificação, foram consideradas duas extensões do CloudSim: o
NetworkCloudSim e o PowerCloudSim. O primeiro permite representar equipamentos de
rede, porém, como descrito no capítulo 2, é focado no tráfego da rede e não possui recursos
para modelar o consumo de energia, o que obrigaria alterar todas as classes existentes, além
de criar novas. Já o segundo, apesar de não possuir recursos para representar equipamentos de
rede, permite o cálculo do consumo energético do datacenter e a migração de máquinas
virtuais. Foi decidido, então, utilizar como base o PowerCloudSim, de Beloglazov e Buyya
(2012), e estender suas funcionalidades para representar, gerenciar e calcular o consumo da
rede.
O simulador estendido foi chamado NetPowerCloudSim e acrescenta as classes
PowerSwitch, herdada pelas classes PowerSwitchAcesso, PowerSwitchAgregacao e
PowerSwitchNucleo; NetPowerDatacenter; GerenciadorRede; e TopologiaRede, descritas nas
subseções a seguir.
48
3.4.2.1 PowerSwitch
Esta classe representa um equipamento de rede do tipo switch e é estendida pelas
classes PowerSwitchAcesso, PowerSwitchAgregacao e PowerSwitchNucleo, que representam
switches das camadas de acesso, de agregação e de núcleo, respectivamente.
Cada switch armazena seu estado, que pode ser ligado ou desligado; o estado de
cada porta, que indica se está desativada ou sua velocidade (Fast Ethernet, Giga Ethernet, 10
Giga Ethernet, 40 Giga Ethernet ou 100 Giga Ethernet); seu consumo atual; seu consumo
quando o frame iniciou; a largura de banda agregada; a quantidade de portas; a quantidade de
portas de uplink; e a quantidade de portas ativas.
Os switches possuem métodos que permitem ligá-los e desligá-los, bem como
ligar e desligar portas específicas e reduzir ou aumentar sua velocidade. É possível ainda
calcular seu consumo atual, a energia consumida durante um frame da simulação e a largura
de banda agregada. Esta última constitui a soma das larguras de banda de todas as portas de
downlink ativas.
A energia consumida por um switch durante um frame da simulação é calculada
por interpolação linear dos valores de consumo do switch no início do frame e o consumo
atual. O Erro! Autoreferência de indicador não válida. exibe o código do método que
realiza este cálculo.
Quadro 3 – Código do método que calcula a energia consumida por um switch durante um frame da
simulação.
As classes PowerSwitchAcesso e PowerSwitchAgregacao possuem métodos para
verificar se a largura de banda agregada ultrapassou ou baixou do limite estabelecido, que são
usados pelo gerenciador da rede para decidir se a velocidade das portas de uplink dos switches
da camada imediatamente superior deve ser, respectivamente, aumentada ou reduzida.
A classe PowerSwitchNucleo possui métodos que permitem ao gerenciador da
rede ligar um módulo quando está desligado e uma porta é ligada e desligar um módulo
quando não possui mais portas ativas.
49
Para manter a eficiência do código, o consumo atual e a largura de banda agregada
são calculados apenas quando o objeto é criado e são atualizados a cada modificação realizada
em uma porta. Se os valores não fossem mantidos atualizados, ao final de cada frame da
simulação, seria necessário percorrer as portas de todos os switches para calcular seus
consumos e suas larguras de banda agregada. O Quadro 4 mostra o trecho do código para
atualizar o consumo de um switch quando a velocidade de uma porta é aumentada.
Quadro 4 – Trecho de código para atualizar o consumo atual do switch.
3.4.2.2 NetPowerDatacenter
Classe que representa um datacenter com uma rede composta por máquinas
físicas, switches de acesso, switches de agregação e switches de núcleo e permite calcular o
seu consumo durante uma simulação. Possui como atributos o consumo total da rede, o
consumo inicial da rede, o gerenciador da rede, as listas de switches e a informação sobre o
gerenciamento da rede, que pode estar habilitado ou desabilitado.
Esta classe estende a classe PowerDatacenter, que, por sua vez, estende a classe
Datacenter para acrescentar-lhe a capacidade de calcular o consumo energético do datacenter
e de realizar migração de máquinas virtuais. Assim como as classes que estende, a
NetPowerDatacenter é uma entidade e, portanto, pode comunicar-se com outras entidades do
CloudSim por meio da criação de eventos e do envio de mensagens e é responsável pelo
avanço da simulação.
Esta classe sobrescreve os métodos updateCloudletProcessing e processVmMigrate do PowerDatacenter, que são responsáveis por processar eventos da simulação, isto é,
realizar as ações necessárias quando finaliza a execução de uma aplicação ou a migração de
uma máquina virtual, respectivamente. Os métodos sobrescritos são invocados pelo núcleo do
simulador ao final de cada frame da simulação, de acordo com o tipo de evento que o
provocou. Após chamar o método correspondente da classe pai para atualizar o estado das
máquinas físicas e virtuais e do datacenter, invocam os métodos verificaMudancaEstadoHost
e calculaConsumoRedeFrame para atualizar o estado da rede.
50
O método verificaMudancaEstadoHost (Quadro 5) verifica a mudança de estado
de cada máquina física do datacenter e a informa ao gerenciador da rede para que este a
reconfigure.
Quadro 5 – Trecho de código do método verificaMudancaEstadoHost.
O método calculaConsumoRedeFrame, por sua vez, calcula a quantidade de
energia elétrica consumida por cada switch durante o frame e acumula os valores em uma
variável que representa o consumo da rede no frame. Se o gerenciamento da rede não estiver
habilitado, a energia consumida em cada frame é calculada diretamente através da
multiplicação do consumo inicial da rede pela duração do frame.
3.4.2.3 TopologiaRede
Classe responsável por definir e representar a topologia da rede através das
quantidades de racks, de switches de acesso, de switches de agregação, de switches de núcleo
e de módulos por switch de núcleo e das interconexões entre seus componentes.
Antes de iniciar a simulação, a partir da quantidade de máquinas físicas presentes
no datacenter, o método defineTopologia calcula a quantidade de racks necessários para
51
acomodá-las. As quantidades de switches de acesso, de agregação e de núcleo são, então,
calculadas a partir da quantidade de racks. O Quadro 6 apresenta o trecho de código no qual
são realizados estes cálculos.
Quadro 6 – Trecho do método que calcula as quantidades de racks, de switches de acesso, de switches de
agregação, de switches de núcleo e de módulos por switch de núcleo.
Devido à topologia padrão estabelecida no modelo, existe uma relação matemática
entre o id de cada elemento da rede e o id do equipamento e o número das portas aos quais
está conectado. Portanto, não há necessidade de armazenar as interconexões entre todos os
componentes em estruturas de dados na classe. Quando a informação é requerida pelo
simulador, a classe calcula os switches e as portas correspondentes através de fórmulas.
Considera-se que os componentes da rede não podem ser conectados a uma porta diferente da
que lhe corresponde de acordo com a topologia padrão.
Como exemplo, é exibido no Quadro 7 o código do método que calcula os ids dos
switches de acesso e o número das portas correspondentes a uma máquina física a partir de
seu id.
52
Quadro 7 – Código do método que calcula os ids dos switches de acesso e o número das portas aos quais
uma máquina física está conectada.
3.4.2.4 GerenciadorRede
Classe que representa um gerenciador cuja função é reconfigurar a rede ao final de
cada frame da simulação de acordo com as mudanças de estado das máquinas físicas. O
gerenciador da rede age de acordo com as regras definidas no modelo, que determinam
quando reduzir ou aumentar a velocidade de portas; ligar ou desligar portas; e ligar ou
desligar módulos e switches.
Antes de iniciar a simulação, o método desligaPortasSemUso, com o auxílio da
classe TopologiaRede determina quais são as portas que não possuem equipamentos
conectados e as desliga (Quadro 8). Este método também verifica se a largura de banda
agregada dos switches que tiveram portas desligadas baixou do limite estabelecido para
determinar se a velocidade de suas portas de uplink deve ser reduzida.
Quadro 8 – Trecho de código do método desligaPortasSemUso que desliga as portas sem uso dos dois
últimos switches de acesso.
53
O método atualizaRede, invocado pela classe NetPowerDatacenter quando há
uma mudança de estado em uma máquina física, recebe o id da máquina e o tipo de mudança
ocorrida e chama os métodos do objeto TopologiaRede para calcular a hierarquia de conexões
entre equipamentos e o método correspondente para reconfigurar a rede.
Quando uma máquina física é desligada, por exemplo, o gerenciador da rede
desliga as portas dos switches de acesso às quais a máquina está conectada e verifica se ainda
há portas ligadas em tais switches. Se não houver, o gerenciador desliga os switches. Se
houver, verifica se a largura de banda agregada dos switches de acesso baixou do limite
estabelecido. Caso esta condição seja verdadeira, a velocidade das portas é reduzida. O
gerenciador, então, realiza as verificações e configurações necessárias nos switches de
agregação e de núcleo, se estes existirem. A lógica completa do processo de reconfiguração
da rede de acordo com as mudanças de estado das MFs está representada no diagrama de
atividades apresentado na seção 3.3.4.
3.4.2.5 Classe principal e interface gráfica
Para a realização de experimentos, foi desenvolvida uma classe principal,
responsável por criar o cenário, iniciar a simulação e recuperar os resultados. Nela são
configuradas as características de todos os objetos necessários para a simulação e os
parâmetros da mesma.
A fim de facilitar a execução de simulações, esta classe recebe valores ingressados
através de uma interface gráfica, que possibilita definir o cenário e as características das
simulações sem a necessidade de modificar ou criar código-fonte. Esta interface permite
determinar a quantidade e características das máquinas físicas, das máquinas virtuais e das
aplicações; indicar se a simulação deve considerar a rede e como esta deve ser gerenciada;
habilitar a migração de MVs; e definir o tempo de operação do datacenter a ser simulado. É
possível ainda, através desta interface, modificar os consumos base de cada tipo de switch e
os consumos das portas de acordo com sua velocidade.
Ao executar uma simulação, a topologia da rede gerada, seu consumo inicial e os
resultados são mostrados na interface e podem ser salvos em arquivos de texto. É possível
ainda definir onde os logs da simulação devem ser salvos. Na Figura 15, é mostrada a tela
principal do simulador.
54
Figura 15 – Tela principal do NetPowerCloudSim.
3.5 TESTES
Nesta seção, são apresentados os testes de unidade e de integração realizados no
código implementado e a validação dos requisitos funcionais e não funcionais.
3.5.1 Testes de Unidade
Os testes de unidade foram realizados com o framework JUnit para verificar a
correção do código de cada classe usando valores que levam a condições limítrofes e
percorrem todos os caminhos possíveis.
Como exemplo, são apresentados os testes realizados na classe TopologiaRede. O
método defineTopologia foi testado verificando se os valores dos atributos modificados por
ele correspondiam aos valores esperados. Para os testes deste método, foram utilizadas as
seguintes quantidades de máquinas físicas: 1, 20, 40, 41, 60, 80, 81, 300, 480, 481, 5760,
5761 e 7000.
55
Para testar o método calculaSwitchAcessoEporta, os ids de máquinas físicas
utilizados foram: 0, 1, 20, 39, 40, 60, 79, 479, 480 e 5760. O código gerado pelo JUnit para
este método e adaptado para o teste com id igual a 479 é apresentado no Quadro 9. Já os
métodos
calculaSwitchAgregacaoEporta
e
calculaModuloSwitchNucleoEporta
foram
testados com a mesma série de valores de ids de switches de acesso e de agregação,
respectivamente: 0, 1, 22, 23, 24, 30 e 100.
Quadro 9 – Código gerado pelo JUnit para teste do método calculaSwitchAcessoEporta e adaptado com id
de máquina física e resultados esperados.
A seguir, na Figura 16, são apresentados os resultados dos testes de unidade da
classe TopologiaRede.
56
Figura 16 – Resultados dos testes de unidade da classe TopologiaRede.
3.5.2 Testes de Integração
Para verificar a correção dos algoritmos criados para definir a topologia e para
reconfigurar a rede, bem como as rotinas de criação e de cálculo do consumo dos
componentes da rede, foi implementada uma classe que permite testar o modelo da rede e seu
funcionamento interagindo com as classes do CloudSim mas sem iniciar uma simulação.
A partir da definição da quantidade de máquinas físicas desejada, esta classe
permite realizar testes de integração, criando um datacenter e os demais objetos necessários
para compor um cenário de simulação. Com o cenário definido, a classe calcula a topologia e
o consumo inicial da rede; desliga as portas sem uso e informa o consumo com esta
configuração, além de mostrar os atributos e o estado de cada porta de todos os switches.
Para testar a interação dos métodos de reconfiguração da rede da classe
GerenciadorRede com os switches e com o datacenter, esta classe permite também ligar e
desligar uma máquina física ou um conjunto de máquinas físicas informando, entre outros
atributos, o consumo e o estado das portas dos switches que foram modificados.
57
3.5.3 Validação de requisitos
A validação foi realizada e homologada em conjunto com os autores do modelo
de gerenciamento. Todos os requisitos funcionais e não funcionais listados na seção 3.2 foram
contemplados na implementação do NetPowerCloudSim e, portanto, validados.
3.6 SIMULAÇÕES E RESULTADOS
A fim de validar as extensões desenvolvidas, foram realizados três experimentos
em uma mesma máquina e com diferentes cenários. Os experimentos são compostos por
simulações executadas em um microcomputador, cujas características são: processador Intel
Core i5-3230M 2,6 GHz; memória RAM de 4 GB DDR3; e sistema operacional Windows 8
de 64 bits.
Os três cenários criados para os experimentos possuem os seguintes parâmetros
comuns: 1 datacenter; máquinas físicas com 8 núcleos de processamento com capacidade de
execução de 2000 MIPS cada, 8 GB de memória RAM, capacidade de armazenamento de 1
TB e largura de banda de 1 Gbps; máquinas virtuais com 2 núcleos de processamento de 1000
MIPS cada, 1 GB de RAM e largura de banda igual a 100 Mbps.
Os experimentos realizados e os resultados obtidos são descritos e discutidos a
seguir.
3.6.1 Experimento 1
Neste experimento, foi simulado um datacenter com apenas 2 máquinas físicas, 4
máquinas virtuais e 4 aplicações, operando durante 1 hora, com a finalidade de verificar o
correto funcionamento das extensões e sua interação com o CloudSim. Foi repetida a
simulação quatro vezes: a primeira com a versão original do CloudSim; a segunda com o
NetPowerCloudSim sem representar a rede; a terceira com representação da rede, mas sem
gerenciamento; e a última com rede gerenciada. Os resultados e os logs de cada simulação
foram comparados entre si e com os resultados esperados e foram realizados os ajustes
necessários para garantir a correção e a coerência do modelo.
Este experimento permitiu avaliar todas as funcionalidades das extensões
desenvolvidas, uma vez que, apesar da simplicidade do cenário, acontecem migrações de
máquinas virtuais, desligamentos de MFs, reduções e aumentos das taxas de utilização de
58
MFs, e, consequentemente, configurações de velocidade e desligamentos de portas de
equipamentos de rede.
O Quadro 10 apresenta os resultados desta simulação. Pode-se observar que,
como esperado, o consumo do datacenter se manteve constante em todas as repetições da
simulação e o consumo da rede foi maior quando não gerenciada. Observa-se também que o
consumo da rede possui valor muito próximo ao do consumo do datacenter. Isto acontece
porque foi montado um rack com dois switches de acesso para apenas duas máquinas físicas,
o que, na prática, não aconteceria.
Quadro 10 – Resultados do Experimento 1.
Tempo de
execução (ms)
Consumo
inicial da rede
(W)
Consumo do
datacenter
(kWh)
Consumo da
rede (kWh)
Consumo total
(kWh)
Número de
migrações de
MVs
Número de
desligamentos
de MFs
PowerCloudSim
NetPowerCloudSim
sem rede
NetPowerCloudSim
sem gerenciamento
da rede
NetPowerCloudSim
com gerenciamento
da rede
69
67
77
109
-
-
188
124
0,1304
0,1304
0,1304
0,1304
-
-
0,1723
0,1076
0,1304
0,1304
0,3027
0,2380
2
2
2
2
1
1
1
1
3.6.2 Experimento 2
Neste experimento, foram simuladas seis horas de operação de um datacenter
com 500 MFs, para que a rede fosse composta pelas três camadas da topologia. Foram
executadas 2.000 MVs e 2.000 aplicações, de forma que houvesse uma quantidade
considerável de migrações de máquinas virtuais e desligamentos de máquinas físicas. A
simulação foi repetida três vezes: a primeira sem gerenciamento da rede; a segunda sem
gerenciamento, mas desligando as portas sem uso na configuração inicial; e a última com
gerenciamento da rede.
59
Os resultados obtidos são apresentados no Quadro 11, no qual se observa que o
consumo da rede sem gerenciamento foi de 32,2104 kWh; que, ao desligar as portas sem uso
na configuração inicial, houve uma economia de 4,402 kWh (13,66%); e que, com
gerenciamento dos equipamentos de rede, a economia foi de 6,8461 kWh (21,25%). Se
considerado o consumo total do datacenter (401,6161 kWh), a economia com as portas sem
uso desligadas foi de 1,09% e com gerenciamento da rede foi de 1,70%.
Quadro 11 – Resultados do Experimento 2.
Sem
gerenciamento
da rede
Tempo de
execução
Consumo
inicial da rede
(W)
Consumo do
datacenter
(kWh)
Consumo da
rede (kWh)
Consumo
total (kWh)
Número de
migrações de
MVs
Número de
desligamentos
de MFs
Sem gerenciamento
da rede (portas sem
uso desligadas)
Com gerenciamento
da rede
00:02:32.565
00:02:33.359
00:02:37.299
5.444,00
4.700,00
4.700,00
369,4057
369,4057
369,4057
32,2104
27,8084
25,3643
401,6161
397,2141
394,7700
1268
1268
1268
250
250
250
O gráfico da Figura 17 mostra a evolução do consumo da rede durante as 6 horas
de operação do datacenter, representando o valor acumulado do consumo em kWh ao final de
cada frame da simulação.
60
Figura 17 – Gráfico da evolução do consumo da rede no Experimento 2.
Tempo (s)
3.6.3 Experimento 3
Neste experimento, foram simuladas seis horas de operação de um datacenter
composto por 5.760 máquinas físicas, 10.000 máquinas virtuais e 10.000 aplicações, com o
objetivo de mostrar o funcionamento do simulador representando um datacenter de grande
porte e verificar a eficiência do código implementado, bem como o cumprimento do requisito
não funcional RN02. Assim como no Experimento 2, a simulação foi repetida três vezes: a
primeira sem gerenciamento de rede; a segunda sem gerenciamento, mas desligando as portas
sem uso na configuração inicial; e a última com gerenciamento da rede.
A partir dos resultados do experimento, apresentados no Quadro 12, é possível
observar que o consumo da rede sem gerenciamento foi de 211,06032 kWh; que, desligando
as portas sem uso na configuração inicial, houve uma economia de 6,81603 kWh (3,23%); e
que, com gerenciamento dos equipamentos de rede, a economia foi de 97,91911 kWh
(46,39%). Se considerado o consumo total do datacenter (2.071,77227 kWh), a economia
61
com as portas sem uso desligadas foi de 0,33% e com gerenciamento da rede, de 4,73%.
Observa-se ainda que o tempo de execução da simulação com gerenciamento da rede foi de
aproximadamente 27 minutos e, portanto, o requisito não funcional RN02 foi atendido.
Quadro 12 – Resultados do Experimento 3.
Sem
gerenciamento
da rede
Tempo de
execução
Consumo
inicial da rede
(W)
Consumo do
datacenter
(kWh)
Consumo da
rede (kWh)
Consumo
total (kWh)
Número de
migrações de
MVs
Número de
desligamentos
de MFs
Sem gerenciamento
da rede (portas sem
uso desligadas)
Com gerenciamento
da rede
00:24:49.597
00:25:28.382
00:27:09.126
3.5672,00
3.4520,00
3.4520,00
1.860,71195
1.860,71195
1.860,71195
211,06032
204,24429
113,14121
2.071,77227
2.064,95624
1.973,85316
12.177
12.177
12.177
4.510
4.510
4.510
O gráfico da Figura 18 mostra a evolução do consumo da rede durante a operação
do datacenter.
62
Figura 18 – Gráfico da evolução do consumo da rede no Experimento 3.
Tempo (s)
63
4 CONCLUSÕES
A Computação em Nuvem é um paradigma que oferece infraestrutura, plataforma
de desenvolvimento e aplicativos como serviço, sob demanda e cobrados por uso. Da
preocupação com o uso sustentável dos recursos, surge o conceito de Computação em Nuvem
Verde, que visa, entre outros objetivos, a economia de energia nos datacenters, nos quais a
Nuvem é implementada, por meio de modelos de gerenciamento.
Estes modelos podem ser testados e validados através de simulações, modelos
analíticos ou testes em ambientes reais. A primeira constitui uma alternativa apropriada, uma
vez que os modelos analíticos ou matemáticos podem apresentar baixa acurácia e fidelidade e
a realização de testes em ambientes reais pode ser inviável, devido ao alto custo de aquisição
e implantação de recursos e à impossibilidade de repetir testes e controlar o tempo.
Neste trabalho, foram realizadas extensões ao simulador CloudSim para
possibilitar a realização dos testes necessários para a validação de um modelo de
gerenciamento de equipamentos de rede legados em um ambiente computacional de nuvem
verde.
Para representar os equipamentos de rede, foi desenvolvida a classe PowerSwitch,
que é estendida por classes que representam switches específicos de cada camada da topologia
(acesso, agregação e núcleo) e permite calcular o seu consumo em um determinado momento,
bem como a energia consumida durante um frame da simulação.
Para representar a topologia da rede, foi criada a classe TopologiaRede,
responsável por calcular as quantidades de cada tipo de equipamento que compõe a rede do
datacenter a partir do número de máquinas físicas, e suas interligações.
Foi implementada ainda a classe GerenciadorTopologia, que contém os atributos e
a lógica necessária para ligar e desligar equipamentos de rede e portas, e configurar a
velocidade destas, conforme as mudanças de estado das máquinas físicas e com base nas
regras e crenças do modelo de gerenciamento.
Finalmente,
foi
estendida
a
classe
PowerDatacenter
pela
classe
NetPowerDatacenter para integrar o modelo de rede ao CloudSim, mediante a interação com
os eventos gerados por outras entidades do simulador. Em cada frame da simulação, esta
classe acrescenta o consumo da rede ao consumo total do datacenter e informa ao gerenciador
da rede as mudanças de estado de cada servidor físico para que este reconfigure os
equipamentos de rede conforme as regras.
64
Para facilitar a realização de experimentos, foi desenvolvida uma interface gráfica
que permite definir o cenário e repetir simulações com diferentes parâmetros sem a
necessidade de modificar o código-fonte.
A correção das extensões foi verificada através de testes de unidade e o modelo de
rede foi validado de forma independente do CloudSim por meio de uma classe de teste de
integração.
Finalmente, foram realizados experimentos com diferentes cenários, que
demonstraram o correto funcionamento do gerenciamento da rede durante a simulação, bem
como o aprimoramento do simulador, acrescentando o consumo da rede ao consumo total do
datacenter e permitindo verificar os efeitos da aplicação do modelo de gerenciamento dos
equipamentos de rede.
Desta forma, a principal contribuição do NetPowerCloudSim foi acrescentar ao
CloudSim a capacidade de representar a rede do datacenter e seu gerenciamento, bem como
seu consumo, o que viabiliza a realização de experimentos de gerenciamento de equipamentos
de rede em nuvem verde para a validação e aprimoramento de estratégias de consolidação de
carga de máquinas físicas considerando os efeitos da consolidação do tráfego da rede.
Como trabalhos futuros, sugere-se implementar novas funcionalidades ao
simulador, como a capacidade de representar equipamentos de rede de tecnologia verde; a
criação de políticas de alocação de máquinas virtuais e cargas de trabalho para representar o
OTM; a realização do cálculo de violações ao SLA causadas pela ativação e desativação dos
equipamentos de rede; e a extensão do modelo para representar e permitir o uso de outras
topologias de rede utilizadas em datacenters modernos. Finalmente, propõe-se realizar
experimentos para validar a confiabilidade do simulador e a adequada escolha dos parâmetros
de configuração, por meio da comparação dos resultados obtidos através de simulações com
os obtidos em cenários de nuvem reais.
65
REFERÊNCIAS
AMAZON. Amazon Elastic Compute Cloud (Amazon EC2). Seatle, 2013. Disponível em:
<http://aws.amazon.com/pt/ec2/>. Acesso em: 06 jun. 2013.
ARMBRUST, M. et al. A view of cloud computing. Communications of the ACM, v. 53, n.
4, p. 50-58, 2010.
BANKS, J. Introduction to simulation. Simulation Conference Proceedings, 1999 Winter,
IEEE, v. 1, p. 7-13, 1999.
BELOGLAZOV, A. et al. A taxonomy and survey of energy-efficient data centers and cloud
computing systems. Advances in Computers, v. 82, n. 2, p. 47-111, 2011.
BELOGLAZOV, A.; BUYYA, R. Optimal Online Deterministic Algorithms and Adaptive
Heuristics for Energy and Performance Efficient Dynamic Consolidation of Virtual Machines
in Cloud Data Centers, Concurrency and Computation: Practice and Experience (CCPE),
v. 24, n. 13, p. 1397-1420, John Wiley & Sons, New York, USA, 2012.
BELOGLAZOV, A. Energy-Efficient Management of Virtual Machines in Data Centers
for Cloud Computing. Melbourne, 2013. 235 f. Tese (Doutorado em Ciência da
Computação). Universidade de Melbourne.
BOSE, S. et al. SLA Management in Cloud Computing: A service provider’s perspective.
Cloud computing: Principles and Paradigms. Wiley: Hoboken, 2011.
BUYYA, R.; YEO, C. S.; VENUGOPAL, S. Market-oriented cloud computing: Vision, hype,
and reality for delivering IT services as computing utilities. Proceedings of the 10th IEEE
International Conference on High Performance Computing and Communications
(HPCC 2008, IEEE CS Press, Los Alamitos, CA, USA), Dalian, set. 2008.
BUYYA, R.; BELOGLAZOV, A.; ABAWAJY, J. Energy-efficient management of data
center resources for cloud computing: A vision, architectural elements, and open
challenges. 2010.
CALHEIROS, R. et al. CloudSim: a Toolkit for Modeling and Simulation of Cloud
Computing Environments and Evaluation of Resource Provisioning Algorithms. Software:
Practice and Experience (SPE), Nova York, v. 41, n. 1, p. 23-50, jan. 2011.
CARSON, J. S. Introduction to modeling and simulation. Proceedings of the 36th
conference on Winter simulation, p. 9-16, dez. 2004.
CELESTI, A. et al. An Approach for the Composition of Generic Cloud-Based Services
Using XRI-Based APIs for Enabling New E-Business. International Journal of E-Business
Development, v. 3, n. 2, p. 64-74, mai. 2013.
CHAVES, S. A.; URIARTE, R. B.; WESTPHALL, C. B. Toward an architecture for
monitoring private clouds. IEEE Communications Magazine, v. 49, n. 12, p. 130-137, dez.
2011.
66
FAYAD, M.; SCHMIDT, D. Object-oriented application framework. Communications of
the ACM, v. 40, p. 32-38, 1997.
FREITAS FILHO, P. J. Introdução à modelagem e Simulação de Sistemas com
Aplicações em Arena. Florianópolis: Visual Books, 2008.
GARG, S. K.; BUYYA, R. NetworkCloudSim: Modelling Parallel Applications in Cloud
Simulations. Fourth IEEE International Conference on Utility and Cloud Computing, p.
105-113, 2011.
GERONIMO, G. A. Estratégia para otimizar a Alocação de Máquinas Virtuais em
Nuvens Verdes. Florianópolis, 2012. Dissertação (Mestrado em Ciências da Computação).
Universidade Federal de Santa Catarina.
GOOGLE. Google Apps for business. Mountain View, 2013. Disponível em:
<http://www.google.com/intx/pt-BR/enterprise/apps/business/>. Acesso em: 06 jun. 2013.
JARARWEH, Y. et al. TeachCloud: A Cloud Computing Educational Toolkit. The 1st
International IBM Cloud Academy Conference, North Carolina, 2012.
MELL, P.; GRANCE, T. The NIST definition of cloud computing (draft). NIST special
publication, v. 800, p. 145, 2011.
MENASCE, D. A., ALMEIDA, V. A., DOWDY, L. W. Performance by design: computer
capacity planning by example. New Jersey: Prentice Hall PTR, 2004.
PFLEEGER, S. L. Engenharia de software: teoria e prática. 2 ed. São Paulo: Prentice Hall,
2004.
MICROSOFT.Windows Azure. Redmond, 2013. Disponível em:
<http://www.windowsazure.com/pt-br/>. Acesso em: 06 jun. 2013.
SÁ, T. T. CloudReports: A simulation tool for Cloud Computing environments. 2013.
Disponível em: <https://github.com/thiagotts/CloudReports>. Acesso em: 20 jun. 2013.
SHANNON, R. E. Introduction to the art and science of simulation. Simulation Conference
Proceedings, IEEE, p. 7-14, 1998.
SUN MICROSYSTEMS. Introduction to Cloud Computing Architecture. 2009. Disponível
em: <https://java.net/jira/secure/attachment/29265/CloudComputing.pdf>. Acesso em: 06 jun.
2013.
TAURION, C. Cloud Computing: Computação em Nuvem: Transformando o mundo da
Tecnologia da Informação. Rio de Janeiro: Brasport, 2009.
VILLARREAL, S.; WESTPHALL C. B. Otimização de Nuvem Verde Mediante o
Gerenciamento de Equipamentos de Rede Legados. International Conference on
Networking, Sevilha, jan. 2013.
67
VOORSLUYS, W.; BROBERG, J.; BUYYA, R. Introducing to cloud computing. Cloud
computing: Principles and Paradigms. Wiley: Hoboken, 2011.
WERNER, J. et al. Aperfeiçoando a gerência de recursos para nuvens verdes. 2012.
WERNER, J. Uma Abordagem para Alocação de Máquinas Virtuais em Ambientes de
Computação em Nuvem Verde. Florianópolis, 2011. Dissertação (Mestrado em Ciências da
Computação). Universidade Federal de Santa Catarina.
WESTPHALL C. B; VILLARREAL, S. Princípios e Tendências em Green Cloud
Computing. Revista Eletrônica de Sistemas de Informação, v. 12, n. 1, p. 1-19, jan-mai
2013.
68
APÊNDICE A – Detalhamento dos Casos de Uso
Quadro 13 – Detalhamento do caso de uso UC01.
UC01 – Definir cenário
Descrição
Ator
Pré-condição
Pós-condição
Fluxo principal
Fluxo alternativo 1
Fluxo alternativo 2
São definidos os valores das variáveis que
compõem o cenário da simulação.
Usuário.
Não existe.
Cenário definido.
1. O usuário informa as características das
máquinas físicas.
2. O usuário informa as características das
máquinas virtuais.
3. O usuário informa as características das
aplicações.
4. O usuário indica o tipo de
gerenciamento da rede.
5. O usuário informa o tempo de operação
do datacenter a ser simulado.
1. O usuário modifica as crenças do
modelo (consumo base de cada tipo de
switch e consumo por tipo de porta).
1. Nos itens 1, 2 ou 3, o usuário digita um
valor inválido.
2. A aplicação informa o erro.
3. A aplicação restaura o valor padrão do
campo de texto.
Quadro 14 – Detalhamento do caso de uso UC02.
UC02 – Iniciar simulação
Descrição
Ator
Pré-condição
Pós-condição
Fluxo principal
Os dados do cenário definido são passados
para o simulador e a simulação é iniciada.
Usuário.
Cenário definido.
Simulação iniciada.
1. O usuário pressiona o botão para iniciar
a simulação.
2. A aplicação transfere os dados do
cenário definido pelo usuário para o
simulador.
3. A aplicação cria o cenário (UC03) e a
topologia (UC04).
4. A simulação inicia.
69
Quadro 15 – Detalhamento do caso de uso UC03.
UC03 – Criar cenário
Descrição
Ator
Pré-condição
Pós-condição
Fluxo principal
Fluxo alternativo
O datacenter, a topologia da rede e as
aplicações são criados, de acordo com o
cenário definido.
Usuário.
Cenário definido.
Cenário criado.
1. A aplicação cria o broker.
2. A aplicação cria o datacenter.
3. A aplicação cria as máquinas físicas.
4. A aplicação cria as máquinas virtuais.
5. A aplicação cria as aplicações.
6. A aplicação cria a topologia de rede
(UC04).
7. A aplicação calcula o consumo da rede
com todas as portas ligadas.
8. A aplicação informa o consumo da rede.
1. Após o item 7, a aplicação desliga as
portas sem uso dos equipamentos de
rede.
2. A aplicação informa o consumo da rede.
70
Quadro 16 – Detalhamento do caso de uso UC04.
UC04 – Criar topologia
Descrição
A topologia de rede é criada, de acordo
com o cenário definido.
Usuário.
Datacenter e máquinas físicas criados.
Topologia definida e criada.
1. A aplicação calcula a quantidade de
racks de acordo com o número de
máquinas físicas.
2. A aplicação calcula a quantidade de
switches de acesso de acordo com o
número de racks.
3. A aplicação calcula a quantidade de
switches de agregação de acordo com o
número de switches de acesso.
4. A aplicação calcula a quantidade de
módulos dos switches de núcleo de
acordo com a quantidade de switches de
agregação.
5. A aplicação cria uma lista de switches
de acesso.
6. A aplicação cria os switches de acesso e
os adiciona à lista.
1. Após o item 6, a aplicação cria os
switches de agregação (UC05).
Ator
Pré-condição
Pós-condição
Fluxo principal
Fluxo alternativo
Quadro 17 – Detalhamento do caso de uso UC05.
UC05 – Criar switches de Agregação
Descrição
Ator
Pré-condição
Pós-condição
Fluxo principal
Fluxo alternativo
São criados os switches de camada de
agregação.
Usuário.
Datacenter, máquinas físicas e switches
de Acesso criados.
Switches de agregação criados.
1. A aplicação cria uma lista de switches
de agregação.
2. A aplicação cria os switches de
agregação e os adiciona à lista.
1. Após o item 6, a aplicação cria os
switches de núcleo (UC06).
71
Quadro 18 – Detalhamento do caso de uso UC06.
UC06 – Criar switches de Núcleo
Descrição
Ator
Pré-condição
Pós-condição
Fluxo principal
São criados os switches de camada de
núcleo.
Usuário.
Datacenter, máquinas físicas e switches
de acesso e de agregação criados.
Switches de núcleo criados.
1. A aplicação cria uma lista de switches
de Núcleo.
2. A aplicação cria os switches de
Núcleo e os adiciona à lista.
Quadro 19 – Detalhamento do caso de uso UC07.
UC07 – Cancelar simulação
Descrição
Ator
Pré-condição
Pós-condição
Fluxo principal
A simulação em execução é cancelada.
Usuário.
Simulação iniciada.
Simulação cancelada.
1. O usuário pressiona o botão para
cancelar a execução da simulação.
2. A aplicação cancela a simulação.
3. A aplicação informa que a simulação foi
cancelada.
4. A aplicação mostra os resultados
parciais.
72
Quadro 20 – Detalhamento do caso de uso UC08.
UC08 – Salvar resultados
Descrição
Ator
Pré-condição
Pós-condição
Fluxo principal
Fluxo alternativo
Os resultados da simulação são salvos em
um arquivo de texto.
Usuário.
Simulação finalizada corretamente.
Arquivo salvo.
1. O usuário pressiona o botão para salvar
os resultados da simulação.
2. A aplicação mostra a janela de pastas do
sistema.
3. O usuário seleciona o local para salvar o
arquivo.
4. O usuário informa o nome do arquivo.
5. A aplicação grava o arquivo no disco.
1. Nos itens 2, 3 ou 4, o usuário cancela a
operação.
Quadro 21 – Detalhamento do caso de uso UC09.
UC09 – Salvar logs
Descrição
Ator
Pré-condição
Pós-condição
Fluxo principal
Os logs da simulação são salvos em um
arquivo de texto.
Usuário.
Simulação iniciada.
Arquivo salvo.
1. O usuário pressiona o botão para
selecionar o diretório em que os logs da
simulação devem ser salvos.
2. A aplicação mostra a janela de pastas
do sistema.
3. O usuário seleciona o local para salvar
o arquivo.
4. O usuário informa o nome do arquivo.
5. A aplicação grava os logs no arquivo
durante a simulação.
73
Quadro 22 – Detalhamento do caso de uso UC10.
UC10 – Ligar porta de switch de acesso
Descrição
Ator
Pré-condição
Pós-condição
Fluxo principal
Fluxo alternativo
É ligada a porta do switch de acesso
correspondente a uma máquina física que
foi ligada.
CloudSim.
Porta do switch de acesso desligada.
Porta do switch de acesso ligada e
configuração da rede ajustada conforme as
regras.
1. A aplicação calcula o número do switch
e da porta correspondente à máquina
física.
2. A aplicação verifica se o switch está
ligado.
3. A aplicação liga a porta do switch.
4. A aplicação atualiza o estado da porta
com o valor de velocidade padrão.
5. A aplicação verifica se deve aumentar a
velocidade das portas de uplink.
6. A aplicação atualiza o valor do
consumo atual do switch.
1. No item 2, se o switch está desligado, a
aplicação liga o switch.
2. A aplicação liga as portas de uplink e a
porta do switch agregação
correspondente.
3. A aplicação verifica se deve modificar a
configuração dos switches de agregação
e de núcleo.
74
Quadro 23 – Detalhamento do caso de uso UC11.
UC011 – Desligar porta de switch de acesso
Descrição
É desligada a porta do switch de acesso
correspondente a uma máquina física que
foi desligada.
Ator
CloudSim.
Pré-condição
Porta do switch de acesso ligada.
Pós-condição
Porta do switch de acesso desligada e
configuração da topologia ajustada
conforme as regras.
Fluxo principal
1. A aplicação calcula o número do switch
e da porta correspondente à máquina
física.
2. A aplicação desliga a porta do switch.
3. A aplicação verifica se ainda há alguma
porta ligada.
4. A aplicação atualiza o estado da porta
com valor zero.
5. A aplicação verifica se deve reduzir a
velocidade das portas de uplink.
6. A aplicação atualiza o valor do
consumo atual do switch.
Fluxo alternativo
1. No item 3, se não há portas ligadas, a
aplicação desliga as portas de uplink, a
porta do switch de agregação
correspondente e o próprio switch.
2. A aplicação verifica se deve modificar a
configuração dos switches de agregação
e de núcleo.
75
Quadro 24 – Detalhamento do caso de uso UC12.
UC12 – Reduzir velocidade de porta de switch de acesso
Descrição
É reduzida a velocidade da porta do
switch correspondente a uma máquina
física subutilizada.
Ator
CloudSim.
Pré-condição
Porta do switch ligada com velocidade
Giga Ethernet e conectada a máquina
física com utilização menor ou igual a
30%.
Pós-condição
Velocidade da porta do switch reduzida e
configuração da rede ajustada conforme as
regras.
Fluxo principal
1. A aplicação calcula o número do switch
e da porta correspondente à máquina
física.
2. A aplicação chama o método para
reduzir a velocidade da porta.
3. A aplicação atualiza o estado da porta
para Fast Ethernet.
4. A aplicação atualiza o valor do
consumo atual do switch.
Fluxo Alternativo
1. Após o item 4, a aplicação verifica se
deve modificar a configuração dos
switches de agregação e de núcleo.
76
Quadro 25 – Detalhamento do caso de uso UC13.
UC013 – Aumentar velocidade de porta de switch de acesso
Descrição
É aumentada a velocidade da porta do
switch correspondente a uma máquina
física que voltou ao nível normal de
utilização.
Ator
CloudSim.
Pré-condição
Porta do switch ligada com velocidade
Fast Ethernet e conectada a máquina física
com utilização maior que 30%.
Pós-condição
Velocidade da porta do switch aumentada
e configuração da rede ajustada conforme
as regras.
Fluxo principal
1. A aplicação calcula o número do switch
e da porta correspondente à máquina
física.
2. A aplicação chama o método para
aumentar a velocidade da porta.
3. A aplicação atualiza o estado da porta
Giga Ethernet.
4. A aplicação atualiza o valor do
consumo atual do switch.
Fluxo alternativo
1. Após o item 4, a aplicação verifica se
deve modificar a configuração dos
switches de agregação e de núcleo.
Quadro 26 – Detalhamento do caso de uso UC14.
UC14 – Calcular o consumo da rede no frame
Descrição
A aplicação calcula a energia consumida
pela rede durante um frame da simulação.
Ator
CloudSim.
Pré-condição
Simulação iniciada e topologia criada.
Pós-condição
Consumo da rede durante o frame
calculado.
Fluxo principal
1. A aplicação calcula o consumo de cada
switch durante o frame.
2. A aplicação acumula os consumos em
uma única variável.
3. A aplicação informa o consumo
calculado.
4. A aplicação atualiza o consumo total da
rede com o valor do consumo no frame.