Naylor Garcia Bachiega
Algoritmo de Escalonamento de Instncia de Mquina Virtual na
Computao em Nuvem
So Jos do Rio Preto 2014
Naylor Garcia Bachiega
Algoritmo de Escalonamento de Instncia de Mquina Virtual na
Computao em Nuvem
Dissertao apresentada como parte dos requisitos para obteno do ttulo de Mestre em Cincia da Computao, junto ao Programa de Ps-Graduao em Cincia da Computao, rea de Concentrao - Sistemas de Computao, do Instituto de Biocincias, Letras e Cincias Exatas da Universidade Estadual Paulista Jlio de Mesquita Filho, Campus de So Jos do Rio Preto.
Orientador: Prof. Dr. Roberta Spolon
So Jos do Rio Preto 2014
Bachiega, Naylor Garcia. Algoritmo de escalonamento de instncia de mquina virtual na
computao em nuvem / Naylor Garcia Bachiega. -- So Jos do Rio Preto, 2014
92 f. : il., grfs., tabs. Orientador: Roberta Spolon Dissertao (mestrado) Universidade Estadual Paulista
Jlio de Mesquita Filho, Instituto de Biocincias, Letras e Cincias Exatas
1. Computao. 2. Computao em nuvem. 3. Recursos de redes de computadores. 4. Algortmos de computador. 5. Armazenamento de dados. I. Spolon, Roberta. II. Universidade Estadual Paulista "Jlio de Mesquita Filho". Instituto de Biocincias, Letras e Cincias Exatas. III. Ttulo.
CDU 681.3.025
Ficha catalogrfica elaborada pela Biblioteca do IBILCE UNESP - Cmpus de So Jos do Rio Preto
Naylor Garcia Bachiega
Algoritmo de Escalonamento de Instncia de Mquina Virtual na Computao em Nuvem
Dissertao apresentada como parte dos requisitos para obteno do ttulo de Mestre em Cincia da Computao, junto ao Programa de Ps-Graduao em Cincia da Computao, rea de Concentrao - Sistemas de Computao, do Instituto de Biocincias, Letras e Cincias Exatas da Universidade Estadual Paulista Jlio de Mesquita Filho, Campus de So Jos do Rio Preto.
Comisso Examinadora Prof. Dr. Roberta Spolon UNESP Bauru Orientador Prof. Dr. Antonio Carlos Sementille UNESP Bauru Prof. Dr. Lus Carlos Trevelin UFSCAR So Carlos
So Jos do Rio Preto 19 de maio de 2014
AGRADECIMENTOS
Agradeo primeiramente a Deus, pela existncia de todas as coisas,
inclusive a minha. Em segundo lugar agradeo a minha esposa Kaliane, pela
ajuda, pacincia, compreenso e lealdade ao meu lado nessa fase da minha
vida. Famlia pela pacincia e a distncia que mantive nesses anos.
Em especial, agradeo aos professores Drs. Roberta Spolon e Marcos
Antnio Cavenaghi por ter acreditado, me orientado e por sempre estarem
presentes. Tambm agradeo aos professores Drs. Aparecido Nilceu Marana,
Renata Spolon Lobato, Adriano Cansian, Aleardo Manacero Jr., Hilda Carvalho,
Jos Remo Ferreira Brega e todos os demais professores da ps-graduao.
Ao amigo Henrique Martins, companheiro de mestrado que tanto ajudou
nesses trs anos. Ao Rafael Hamamura e Felipe Maciel pela ajuda e
disponibilidade e todos queles da ps-graduao que de alguma forma
participaram e contriburam para esse trabalho.
E conhecereis a verdade, e a verdade vos libertar.
Yeshua Hamashiach
RESUMO
Na tentativa de reduzir custos aproveitando de maneira eficiente recursos
computacionais, novas tecnologias e arquiteturas desenvolvidas esto
conquistando grande aceitao do mercado. Uma dessas tecnologias a
Computao em Nuvem, que tenta resolver problemas como consumo
energtico e alocao de espao fsico em centros de dados ou grandes
empresas. A nuvem um ambiente compartilhado por diversos clientes e
permite um crescimento elstico, onde novos recursos como hardware ou
software, podem ser contratados ou vendidos a qualquer momento. Nesse
modelo, os clientes pagam por recursos que utilizam e no por toda a
arquitetura envolvida. Sendo assim, importante determinar de forma eficiente
como esses recursos so distribudos na nuvem. Portanto, esse trabalho teve
como objetivo desenvolver um algoritmo de escalonamento para nuvem que
determinasse de maneira eficiente a distribuio de recursos dentro da
arquitetura. Para alcanar esse objetivo, foram realizados experimentos com
gestores de nuvem open-source, detectando a deficincia dos algoritmos
atuais. O algoritmo desenvolvido foi comparado com o algoritmo atual do gestor
OpenStack Essex, um gestor de nuvem open-source. Os resultados
experimentais demonstraram que o novo algoritmo conseguiu determinar as
mquinas menos sobrecarregadas da nuvem, conseguindo desse modo,
distribuir a carga de processamento dentro do ambiente privado.
Palavras-chave: Computao em nuvem. Economia de recursos.
Escalonamento de recursos. Escalonador.
ABSTRACT
In an attempt to reduce costs by taking advantage of efficient computing
resources, new technologies and architectures developed are gaining wide
acceptance in the market. One such technology is cloud computing, which tries
to solve problems like energy consumption and allocation of space in data
centers or large companies. The cloud is an environment shared by multiple
clients and enables elastic growth, where new features such as hardware or
software, can be hired or sold at any time. In this model, customers pay for the
resources they use and not for all the architecture involved. Therefore, it is
important to determine how efficiently those resources are distributed in the
cloud. Therefore, this study aimed to develop a scheduling algorithm for cloud
efficiently determine the distribution of resources within the architecture. To
achieve this goal, experiments were conducted with managers of open-source
cloud, detecting the deficiency of current algorithms. This algorithm was
compared with the algorithm of the OpenStack Essex manager, a manager of
open-source cloud. The experimental results show that the new algorithm could
determine the machines less the cloud overloaded, achieving thereby distribute
the processing load within the private environment.
Keywords: Cloud computing. Resource saving. High availability. Resource
scheduling.
LISTA DE ILUSTRAES
Figura 1 Pesquisa pelo termo: Computao em Nuvem. .............................. 17 Figura 2 Controle de mquinas virtuais pelo hypervisor. ............................... 19 Figura 3 Tipos de servios da Computao em Nuvem. ............................... 20 Figura 4 Modelos da Computao em Nuvem. ............................................. 22 Figura 5 Infraestrutura da Computao em Nuvem. ..................................... 24 Figura 6 Redes virtuais na Computao em Nuvem. .................................... 26 Figura 7 Modelo de nuvem utilizando cache. ................................................ 35 Figura 8 Listagem de processos do KVM no Linux. ...................................... 38 Figura 9 Sistema de escalonamento. ............................................................ 39 Figura 10 Taxonomia de Escalonamento. ..................................................... 40 Figura 11 Seleo de ns nova-scheduler. ................................................ 46 Figura 12 Escalonamento no gestor de nuvem. ............................................ 48 Figura 13 Sistemas operacionais virtualizados com cargas distantes. .......... 50 Figura 14 Perfis de memria. ........................................................................ 50 Figura 15 Sistemas operacionais disponveis para o gestor. ........................ 51 Figura 16 Teste de escalonamento comportamento 1: 08 instncias. ....... 51 Figura 17 Sistemas operacionais virtualizados com cargas aproximadas. ... 52 Figura 18 Teste de escalonamento comportamento 2: 30 instncias. ....... 52 Figura 19 Programa de simulao de consumo varivel. .............................. 53 Figura 20 Teste de escalonamento comportamento 3: 08 instncias. ....... 54 Figura 21 Taxonomia de escalonamento em Grid. ........................................ 55 Figura 22 Tabela de armazenamento das informaes dos ns. .................. 58 Figura 23 Agendamento de execuo de programa (crontab). ..................... 58 Figura 24 Teste do prottipo comportamento 1: 08 instncias. .................. 60 Figura 25 Teste do prottipo comportamento 2: 30 instncias. .................. 60 Figura 26 Teste do prottipo comportamento 3: 08 instncias. .................. 61 Figura 27 Layout de instalao do OpenStack Essex. .................................. 73 Figura 28 Interface Web de gerenciamento Horizon. ................................. 74 Figura 29 Ambiente de Instalao Eucalyptus. .......................................... 75
LISTA DE TABELAS
Tabela 1 Comparao entre os gestores de nuvem. ..................................... 33 Tabela 2 Especificaes dos ns. ................................................................. 49 Tabela 3 Recursos disponveis antes do teste. ............................................. 49 Tabela 4 Especificao de hardware para a nuvem. ..................................... 73
LISTA DE ABREVIATURAS E SIGLAS
AR Advance Reservations
API Application Programming Interface
AWS Amazon Web Services
BGP Border Gateway Protocol
BIOS Basic Input/Output System
CaaS Communications as a Service
CPU Central Processing Unit
DaaS Datacenter as a Service
DDoS Distributed Denial-of-Service
DoS Denial of Service
EBS Amazon Elastic Block Store
EC2 Amazon Elastic Compute Cloud
HaaS Hardware as a Service
HTTP Hypertext Transfer Protocol
HVM Hardware Virtual Machine
IaaS Infrastructure as a Service
iSCSI Internet Small Computer System Interface
IPS Intrusion prevention systems
KaaS Knowledge as a Service
KVM Kernel-based Virtual Machine
LAN Local Area Network
LVM Logical Volume Manager
MB Megabyte
MMU Memory Management Unit
NASA National Aeronautics and Space Administration
NFS Network File System
NTP Network Time Protocol
NUMA Non-uniform Memory Access
OVF Open Virtualization Format
PaaS Platform as a Service
PCI Peripheral Component Interconnect
PHP HyperText PreProcessor
RAM Random Access Memory
RPC Remote Procedure Call
SaaS Software as a Service
SAN Storage Area Network
SCSI Small Computer System Interface
SLA Service Level Agreement
SMP Processor Symmetric Multiprocessing
SO Sistema Operacional
SOAP Simple Object Access Protocol
SQL Structured Query Language
S3 Amazon Simple Storage Service
TLB Translation Address Table
VCL Virtual Computing Lab.
VIM Virtual Infrastructure Manager
VLAN Virtual Local Area Network
VM Virtual Machine
VMM Virtual Machine Monitor
VPN Virtual Private Network
UHCI Universal Host Controller Interface
USB Universal Serial Bus
XML Extensible Markup Language
XSS Cross-site scripting
SUMRIO
1 INTRODUO ............................................................................................ 15
1.1 OBJETIVOS .............................................................................................. 16
1.2 ORGANIZAO DO TEXTO ......................................................................... 16
2 COMPUTAO EM NUVEM ...................................................................... 17
2.1 CONSIDERAES INICIAIS ......................................................................... 17
2.2 DIFERENAS ENTRE VIRTUALIZAO E EMULAO ..................................... 18
2.3 VIRTUALIZAO NA NUVEM ....................................................................... 18
2.4 CLASSES DE SERVIOS DA COMPUTAO EM NUVEM ................................. 20 2.4.1 INFRAESTRUTURA COMO UM SERVIO ............................................... 20 2.4.2 PLATAFORMA COMO UM SERVIO ...................................................... 21 2.4.3 SOFTWARE COMO UM SERVIO ......................................................... 21
2.5 MODELOS DA COMPUTAO EM NUVEM .................................................... 21
2.6 CARACTERSTICAS DA COMPUTAO EM NUVEM ........................................ 22
2.7 INFRAESTRUTURA DA COMPUTAO EM NUVEM ......................................... 23 2.7.1 SUPORTE PARA VIRTUALIZAO ........................................................ 24 2.7.2 PROVISIONAMENTO DE RECURSOS SOB DEMANDA .............................. 24 2.7.3 MLTIPLOS BACKEND HYPERVISORS ................................................. 25 2.7.4 VIRTUALIZAO DE ARMAZENAMENTO ............................................... 25 2.7.5 INTERFACE PARA NUVENS PBLICAS ................................................. 25 2.7.6 REDE VIRTUAL ................................................................................. 26 2.7.7 ALOCAO DINMICA DE RECURSOS ................................................. 26 2.7.8 MECANISMO DE RESERVA E NEGOCIAO ......................................... 27 2.7.9 ALTA DISPONIBILIDADE E RECUPERAO DE DADOS ........................... 27
2.8 PRINCIPAIS GESTORES DA COMPUTAO EM NUVEM .................................. 28 2.8.1 APACHE VCL .................................................................................. 28 2.8.2 CITRIX ESSENTIALS .......................................................................... 28 2.8.3 EUCALYPTUS ................................................................................... 29 2.8.4 NIMBUS3 ......................................................................................... 29 2.8.5 OPENNEBULA .................................................................................. 30 2.8.6 OPENPEX ...................................................................................... 30 2.8.7 OVIRT ............................................................................................. 31 2.8.8 VMWARE VSPHERE ......................................................................... 31 2.8.9 OPENSTACK ESSEX ......................................................................... 32
2.9 LIMITAES ENCONTRADAS COM OS GESTORES ......................................... 34
2.10 CONSIDERAES FINAIS ........................................................................... 36
3 ESCALONAMENTO DE RECURSOS ........................................................ 37
3.1 CONSIDERAES INICIAIS ......................................................................... 37
3.2 ESCALONAMENTO .................................................................................... 38
3.3 TAXONOMIA DE ESCALONAMENTO ............................................................. 39
3.4 BALANCEAMENTO DE CARGA .................................................................... 42 3.4.1 CLASSIFICAO DOS ALGORITMOS DE BALANCEAMENTO DE CARGA ..... 42 3.4.2 ALGORITMOS DE BALANCEAMENTO DE CARGA ................................... 43 3.4.3 MTRICAS PARA BALANCEAMENTO DE CARGA .................................... 44
3.5 ESCALONAMENTO E BALANCEAMENTO NO OPENSTACK ............................. 45
3.6 CONSIDERAES FINAIS ........................................................................... 47
4 METODOLOGIA E PROTTIPO ................................................................ 48
4.1 CONSIDERAES INICIAIS ......................................................................... 48
4.2 METODOLOGIA ......................................................................................... 48 4.2.1 COMPORTAMENTO 1: MQUINAS VIRTUAIS DE CONSUMO CONSTANTE COM CARGAS DISTANTES ................................................................................... 49 4.2.2 COMPORTAMENTO 2: MQUINAS VIRTUAIS DE CONSUMO CONSTANTE COM CARGAS APROXIMADAS ............................................................................. 51 4.2.3 COMPORTAMENTO 3: MQUINAS VIRTUAIS DE CONSUMO VARIVEL ...... 53
4.3 O PROTTIPO .......................................................................................... 54 4.3.1 RECURSOS DOS NS ....................................................................... 56 4.3.2 ESCOLHA DOS NS .......................................................................... 59 4.3.3 COMPORTAMENTO 1: MQUINAS VIRTUAIS DE CONSUMO CONSTANTE COM CARGAS DISTANTES ................................................................................... 59 4.3.4 COMPORTAMENTO 2: MQUINAS VIRTUAIS DE CONSUMO CONSTANTE COM CARGAS APROXIMADAS ............................................................................. 60 4.3.5 COMPORTAMENTO 3: MQUINAS VIRTUAIS DE CONSUMO VARIVEL ...... 61
4.4 CONSIDERAES FINAIS ........................................................................... 61
5 CONCLUSO ............................................................................................. 63
5.1 CONSIDERAES INICIAIS ......................................................................... 63
5.2 CONTRIBUIES ...................................................................................... 64
5.3 TRABALHOS FUTUROS .............................................................................. 65
REFERNCIAS ................................................................................................ 66
GLOSSRIO .................................................................................................... 70
APNDICE A - INSTALAO DO EUCALYPTUS ......................................... 73
APNDICE B - INSTALAO DO OPENNEBULA ........................................ 78
APNDICE C - INSTALAO DO OPENSTACK ESSEX .............................. 81
ANEXO A TEST_NODE_FX.PL ................................................................... 85
ANEXO B TEST_NODE_RAND.PL .............................................................. 87
ANEXO C NODE_RESOURCES.PY ............................................................ 89
ANEXO D CHOICE_NODE.PY ..................................................................... 92
15
1 INTRODUO
Com o aumento constante do uso computacional, problemas como
demanda energtica e espao em centros de dados esto ocorrendo em todo o
mundo. Muitas solues esto sendo projetadas para sanar esse tipo de
situao, entre elas est a Computao em Nuvem (Cloud Computing) (HE;
HE, 2011).
A Computao em Nuvem vista como uma tendncia no cenrio atual
em quase todas as organizaes. As vantagens de usar a computao em
nuvem so: reduo de hardware e custo de manuteno, acessibilidade,
flexibilidade e um processo altamente automatizado em que o cliente no
precisa se preocupar com upgrade de software (BHADAURIA; CHAKI, 2011).
Sabahi (2011) define Computao em Nuvem como sendo um ambiente
de rede baseado no compartilhamento de recursos computacionais. Na
verdade, nuvens so baseadas na Internet e tentam disfarar a complexidade
para os clientes. A Computao em Nuvem refere-se ao hardware e software
entregues como servios por meio da Internet pelos centros de dados.
Empresas que fornecem nuvens utilizam-se de tecnologias de virtualizao,
combinadas com suas habilidades para fornecer recursos de computao por
meio de sua infraestrutura de rede.
Ainda segundo Sabahi (2011), em ambientes de nuvem, vrios tipos de
mquinas virtuais esto hospedados no mesmo servidor fsico como
infraestrutura. Na nuvem, clientes s devem pagar por aquilo que usam e no
devem pagar por recursos locais que precisam como armazenamento ou
infraestrutura.
Ao ligar um aparelho eltrico em uma tomada, ns no nos importamos como a energia eltrica gerada e nem como ela chega a esse estabelecimento. Isto possvel porque eletricidade virtualizada, isto , est prontamente disponvel a partir de uma tomada de parede que esconde estaes de gerao de energia e um enorme grid. Quando essa distribuio estendida a tecnologias de informao, este conceito significa entregar funes teis escondendo como funcionam internamente. A Computao em Nuvem, para ser considerada totalmente virtualizada, deve permitir que os
16
computadores sejam construdos a partir de componentes distribudos tais como os recursos de armazenamento, processamento de dados e software (BUYYA; BROBERG; GOSCISNSKI, 2011).
Nuvens utilizam algoritmos de escalonamento para distribuir recursos
dentro da arquitetura, como por exemplo, instncias de mquinas virtuais que
so oferecidas para clientes como servio. Nesses moldes, determinar o
escalonamento de modo eficiente pode assegurar a qualidade dos servios
oferecidos.
1.1 OBJETIVOS
Tendo em vista que os atuais algoritmos de escalonamento das nuvens
open-source determinam de modo esttico os recursos disponveis, esse
trabalho teve como objetivo criar um algoritmo dinmico de escalonamento
para determinar de modo eficiente quais os ns computacionais dentro de uma
nuvem, possuem recursos para abrigar novas instncias de mquinas virtuais.
Esse algoritmo ainda permite determinar o consumo de recursos fsicos de
cada instncia em um n computacional, permitindo que trabalhos futuros
possam realocar essas instncias, aproveitando a capacidade total do n.
1.2 ORGANIZAO DO TEXTO
Este trabalho foi divido em cinco captulos:
No captulo 2 foi feito um estudo sobre Computao em Nuvem,
levantando as principais caractersticas, arquitetura, modelos de
servios, aspectos de segurana e as principais ferramentas.
No captulo 3 foi apresentado um estudo sobre os algoritmos de
escalonamento de recursos e balanceamento de carga.
No captulo 4 apresentada metodologia e o prottipo
desenvolvido. Tambm so apresentados os resultados e
discusses sobre o trabalho.
No captulo 5 foi apresentada a concluso desse trabalho e
sugestes para estudos futuros.
17
2 COMPUTAO EM NUVEM
Esse captulo apresenta detalhes da arquitetura de nuvem, definindo
seus modelos, caractersticas e tipos, analisando os principais gestores e suas
diferenas.
2.1 CONSIDERAES INICIAIS
O conceito de Computao em Nuvem vem sendo discutido e essa nova
arquitetura tem ganhado repercusso em larga escala. Conforme mostra a
Figura 1, h um crescente aumento em pesquisas pelo Google.
Figura 1 Pesquisa pelo termo: Computao em Nuvem.
Fonte: TRENDS, 2012.
A ideia bsica da arquitetura fornecer poder computacional sob
demanda, onde conforme a necessidade, mais mquinas virtuais podem ser
ativadas na nuvem, oferecendo mais recursos se necessrio, tendo assim um
crescimento elstico, onde mquinas so adicionadas para aumentar o poder
de processamento e/ou armazenamento.
A nuvem utiliza-se de conceitos existentes, como virtualizao e
emulao, e a partir disso monta-se uma nova arquitetura reunindo-os para
atingir seu objetivo, disponibilizando recursos conforme demanda. Segundo
Buyya, Broberg e Goscisnski (2011) a virtualizao de hardware permite criar
18
mltiplas mquinas virtuais sobre uma mquina fsica.
2.2 DIFERENAS ENTRE VIRTUALIZAO E EMULAO
Em um emulador todas as instrues realizadas pela mquina
real so abstradas em um ambiente de software, possibilitando
executar um aplicativo de uma plataforma em outra, por
exemplo, um aplicativo do Windows sendo executado no Linux
ou um aplicativo i386 sendo executado em uma plataforma
Sparc. (LAUREANO, 2006)
Portanto, um emulador tem a capacidade de simular um computador
fsico, este no tem nenhuma relao com o hardware subjacente, assim,
necessrio fornecer todos os dispositivos atravs da transcrio de instrues.
Porm essa emulao causa uma perda de eficincia ao realizar a traduo de
cada instruo da mquina emulada para a mquina fsica. (LAUREANO,
2006)
No caso da virtualizao, um ambiente criado por um monitor de
mquina virtual (Virtual Machine Monitor VMM), sendo este ambiente
controlado pelo hypervisor1. Esse monitor fornece uma interface de hardware
idntica a subjacente atravs da multiplexao, permitindo que instrues que
no comprometam o isolamento das mquinas virtuais sejam executadas
diretamente sobre esse hardware. (LAUREANO, 2006)
2.3 VIRTUALIZAO NA NUVEM
A Computao em Nuvem utiliza-se da virtualizao para criar um
ambiente (nuvem), onde aloca instncias (sistemas operacionais virtualizados)
de acordo com os recursos disponveis (mquinas fsicas). Essas instncias de
mquinas virtuais so alocadas de acordo com as mquinas fsicas que
1 uma camada de software entre o hardware e o sistema operacional, que controla o acesso dos
sistemas operacionais convidados aos dispositivos de hardware (VMWARE, 2012).
19
compem o parque de mquinas da nuvem.
Conforme Figura 2, a virtualizao consiste basicamente na camada que
faz a mediao entre o hardware e a mquina virtual (VM). Largamente
utilizadas, as VMs contriburam no melhor aproveitamento de recursos,
considerando que ocasionalmente um computador atinge a totalidade de sua
capacidade de processamento.
Figura 2 Controle de mquinas virtuais pelo hypervisor.
Fonte: VMWARE, 2012.
A camada de virtualizao formada por um monitor de mquina virtual
(Virtual Machine Monitor VMM), sendo este controlado pelo hypervisor. Esse
monitor fornece uma interface de hardware idntica a subjacente atravs da
multiplexao, permitindo que instrues que no comprometam o isolamento
das mquinas virtuais sejam executadas diretamente sobre esse hardware
(VMWARE, 2012).
Existem no mercado diversas solues para mquinas virtuais, sendo a
maior parte solues open-source, suas diferenas se destacam na gama de
servios oferecidos. Os principais hypervisors atualmente so Xen, VMware,
KVM e QEMU, este ltimo, diferentemente de um virtualizador, um emulador,
em que o hardware totalmente simulado atravs de software (BUYYA;
BROBERG; GOSCISNSKI, 2011).
20
2.4 CLASSES DE SERVIOS DA COMPUTAO EM
NUVEM
Segundo Buyya, Broberg e Goscisnski (2011), a Computao em Nuvem
dividida em trs classes de servios de acordo com o modelo de servios
oferecidos pelos provedores: Infraestrutura como um Servio (IaaS), Software
como um Servio (SaaS) e Plataforma como um Servio (Paas) conforme pode
ser visualizado na Figura 3.
Figura 3 Tipos de servios da Computao em Nuvem.
Fonte: BUYYA; BROBERG; GOSCISNSKI, 2011.
2.4.1 INFRAESTRUTURA COMO UM SERVIO
Nesse tipo de servio, o cliente da nuvem tem a sua disposio
processamento, redes, armazenamento e outros recursos computacionais,
onde poder instalar sistemas operacionais ou qualquer outro sistema prprio.
O cliente no administra ou controla a infraestrutura da nuvem subjacente e
paga somente pela estrutura que utilizar. Pode-se citar como exemplos de
IaaS, servios como Amazon Elastic Compute Cloud (Amazon EC2), Amazon
Simple Storage Service (Amazon S3), Eucalyptus, OpenNebula e OpenStack
21
Essex (SASIKALA, 2012).
2.4.2 PLATAFORMA COMO UM SERVIO
Esse tipo de servio oferece um ambiente para desenvolvedores criarem,
testarem e implantarem suas aplicaes, no se importando com a
infraestrutura, quantidade de memria ou requerimentos de hardware. Pode-se
citar o Google Apps como exemplo desse servio, onde oferecido um
ambiente escalvel para desenvolvimento e hospedagem de aplicaes Web
ou Microsoft Azure (SASIKALA, 2012).
2.4.3 SOFTWARE COMO UM SERVIO
Nesse tipo, as aplicaes residem no topo do modelo, oferecendo
software sob demanda. As aplicaes so acessveis a partir de vrios
dispositivos como um navegador Web, (por exemplo, webmail). O cliente no
administra ou controla a infraestrutura da nuvem, como a rede, servidores,
sistemas operacionais, armazenamento ou mesmo a aplicao. A cobrana do
servio nesse caso pode ser feita com base no nmero de usurios
(SASIKALA, 2012).
Alm dos trs tipos de servios citados acima, outros autores tambm
consideram: CaaS (Comunicaes como um Servio), DaaS (Datacenter como
um Servio), KaaS (Conhecimento como um Servio) e HaaS (Hardware como
um Servio) (HE; HE, 2011).
2.5 MODELOS DA COMPUTAO EM NUVEM
Segundo Sasikala (2012), os modelos de nuvem so definidos de acordo
com o grupo que ir utilizar os servios da arquitetura, estes podem ser de
quatro tipos: nuvem pblica, privada, comunidade e hbrida.
Nuvem Pblica: a infraestrutura fornecida para muitos clientes e
gerenciada por terceiros. Vrias empresas podem trabalhar
simultaneamente na mesma infraestrutura. O usurio paga por
aquilo que utilizar.
Nuvem Privada: infraestrutura disponibilizada apenas para um
22
cliente especfico e gerenciada pela prpria organizao ou por
terceiros. Este utiliza o conceito de virtualizao de mquinas,
usando rede proprietria.
Nuvem Comunidade: infraestrutura compartilhada por vrias
organizaes por uma causa comum, podendo ser gerenciada por
elas mesmas ou por um prestador de servios.
Nuvem Hbrida: compe um ou mais modelos de implantao de
nuvem, em que a comunicao entre elas realizada de modo
transparente (como uma bridge), conforme Figura 4.
Figura 4 Modelos da Computao em Nuvem.
Fonte: THANGARAJ, 2012.
2.6 CARACTERSTICAS DA COMPUTAO EM NUVEM
Segundo Buyya, Broberg e Goscisnski (2011), de acordo com os
modelos de nuvem, esta precisa oferecer alguns servios para que se torne
atraente para os clientes, entre eles, self-service, modo de faturamento,
elstico e que permita customizao.
Self-service: nesse caso, a nuvem deve estar preparada para
receber clientes por demanda e com acesso imediato aos recursos
necessrios, onde se possa pagar, utilizar e customizar os servios
sem interveno de operadores.
Faturamento: a nuvem deve oferecer servio por bilhetagem ou
23
por hora (recursos consumidos), no obrigando o cliente a pagar
por recursos no utilizados.
Elstico: os clientes esperam que a nuvem lhes oferea recursos
sob demanda, tanto para cima quanto para baixo, de acordo com o
uso.
Customizao: em uma nuvem h uma grande disparidade entre
as necessidades do usurio, assim, os recursos alugados a partir
da nuvem devem ser altamente personalizveis. No caso de IaaS,
personalizao significa permitir que os usurios possam implantar
dispositivos virtuais para ter acesso (root) privilegiado a servidores
virtuais. Outras classes de servio (PaaS e SaaS) oferecem menor
flexibilidade e no so adequadas para computao de propsito
geral, mas ainda podem fornecer um certo nvel de personalizao.
2.7 INFRAESTRUTURA DA COMPUTAO EM NUVEM
Conforme Figura 5, a infraestrutura IaaS de uma nuvem conta com o
VIM (Virtual Infrastructure Manager), esse tipo de software se assemelha a um
sistema operacional, porm este agrega recursos de vrios computadores
apresentando uma viso uniforme e aplicaes para o usurio. Tambm pode
ser conhecido como infrastructure sharing software e virtual infrastructure
engine (BUYYA; BROBERG; GOSCISNSKI, 2011).
Segundo Buyya apud Sotomayor et al. (2011), prope uma diferenciao
entre duas categorias de ferramentas utilizadas para gerenciar as nuvens. A
primeira categoria chamada de cloud toolkits inclui softwares que expem
uma interface remota e segura para criar, controlar, visualizar e monitorar
recursos, mas no se especializam em gesto de infraestrutura virtual. A
Segunda categoria chamada Virtual Infrastructure Managers capaz de
gerenciar recursos avanados, tais como balanceamento de carga automtico
e consolidao de servidores. No entanto, os autores ressaltam que h uma
superposio entre as categorias, cloud toolkits tambm podem gerenciar
uma infraestrutura virtual, embora eles normalmente ofeream recursos menos
sofisticados do que gestores especializados nessa infraestrutura.
24
Sendo assim, um software de nuvem precisa ter algumas caractersticas
bsicas e avanadas presentes em um gestor, como poder ser observado nas
sees a seguir.
Figura 5 Infraestrutura da Computao em Nuvem.
Fonte: JONES, 2012A.
2.7.1 SUPORTE PARA VIRTUALIZAO
Uma nuvem deve suportar mltiplos clientes com diferentes necessidades
que sero dimensionadas para um servidor da infraestrutura. Recursos
virtualizados podem ser dimensionados e redimensionados com certa
flexibilidade. Estas caractersticas tornam a virtualizao de hardware, a
tecnologia ideal para criar uma infraestrutura virtual que abrigar vrios clientes
(BUYYA; BROBERG; GOSCISNSKI, 2011). Deve ser capaz de criar e
gerenciar vrios grupos de VM em clusters virtuais. Esse recurso importante
para alocao de recursos sob demanda.
2.7.2 PROVISIONAMENTO DE RECURSOS SOB DEMANDA
Uma das caractersticas altamente desejvel de um gestor a
25
disponibilizao de recursos onde o usurio possa adquiri-los sem a
interveno de um operador humano, como a criao de servidores,
configuraes de segurana e testes de software (BUYYA; BROBERG;
GOSCISNSKI, 2011).
2.7.3 MLTIPLOS BACKEND HYPERVISORS
Alguns gestores devem fornecer uma camada uniforme de gesto,
independentemente da tecnologia de virtualizao utilizada. Esta caracterstica
visvel nos gestores open-source, que geralmente fornecem drivers para
interagir com mltiplos hypervisors. Nesse sentido, o objetivo da libvirt2
fornecer uma API uniforme para gestores, que podem gerenciar domnios (uma
VM ou uma instncia de um sistema operacional) em ns virtualizados usando
operaes padro para chamadas de hypervisors (BUYYA; BROBERG;
GOSCISNSKI, 2011).
2.7.4 VIRTUALIZAO DE ARMAZENAMENTO
A virtualizao de armazenamento (storage) consiste em abstrair
armazenamento lgico a partir de um armazenamento fsico. Ao consolidar
todos os dispositivos de armazenamento disponveis em um centro de dados,
torna-se possvel a criao de discos virtuais independentes do dispositivo e
localizao. Storages normalmente so organizados em Storage Area Network
(SAN) e conectados atravs de protocolos como o Fibre Channel, iSCSI e NFS
(BUYYA; BROBERG; GOSCISNSKI, 2011).
2.7.5 INTERFACE PARA NUVENS PBLICAS
Pesquisadores tm percebido que emprstimo de recursos a partir de
nuvens pblicas vantajoso. Desta forma, as instituies podem fazer bom uso
de seus recursos disponveis e, em caso de picos de demanda, a carga extra
pode ser transferida para recursos alugados, sendo assim, um gestor deve ser
capaz de oferecer um controlador para o ciclo de vida dos recursos
virtualizados obtidos a partir de fornecedores externos de nuvem. Para as
2 Libvirt uma API open-source para gerenciamento de ferramentas de virtualizao, podendo ser
usado para gerenciar Linux KVM, Xen, VMware ESX, entre outros hypervisors.
26
aplicaes, a utilizao dos recursos alugados deve ser transparente (BUYYA;
BROBERG; GOSCISNSKI, 2011).
2.7.6 REDE VIRTUAL
As redes virtuais permitem a criao de uma rede isolada no topo de
uma infraestrutura fsica. Uma LAN Virtual (VLAN) permite isolar o trfego que
compartilha uma rede comutada, permitindo que VMs sejam agrupadas no
mesmo domnio de broadcast, como pode ser observado na Figura 6.
Figura 6 Redes virtuais na Computao em Nuvem.
Fonte: JONES, 2012A.
Alm disso, uma VLAN pode ser configurada para bloquear o trfego
originado de redes de outras VMs. Da mesma forma, o conceito de VPN (rede
privada virtual) usado para descrever uma rede de sobreposio segura e
privada em cima de uma rede pblica (mais comumente a Internet). Sendo
assim, deve existir suporte para esse tipo de rede virtual em um gestor
(BUYYA; BROBERG; GOSCISNSKI, 2011).
2.7.7 ALOCAO DINMICA DE RECURSOS
Em infraestruturas de nuvem, onde as aplicaes possuem
necessidades variveis e dinmicas, existe a necessidade de alocao
dinmica de recursos visando oferta e a demanda, reduo do consumo
27
eltrico e uma melhor gesto dos SLAs3. Mquinas que no esto executando
nenhuma instncia de VM podem ser desligadas ou colocadas em estado de
baixo consumo energtico. Sendo assim, um gestor de VI deve ser capaz de
alocao dinmica de recursos, monitorando continuamente a utilizao do seu
parque de mquinas (BUYYA; BROBERG; GOSCISNSKI, 2011).
2.7.8 MECANISMO DE RESERVA E NEGOCIAO
Quando os usurios solicitarem recursos computacionais para um
momento especfico, os pedidos so chamados de reservas antecipadas (AR),
em contraste com o pedido por melhor esforo, em que recursos so
disponibilizados a partir do momento em que esto disponveis. Nesse caso um
gestor deve permitir alocar recursos por perodos de tempo. Esta caracterstica
ilustrada pelo caso em que uma AR solicitada por um cliente, porm o
provedor no pode oferecer exatamente essa AR, mas pode oferecer uma AR
satisfatria para o cliente. Este problema foi abordado no OpenPEX (gestor de
nuvem), que incorpora um protocolo de negociao bilateral que permite
usurios e provedores uma negociao sobre o servio (BUYYA; BROBERG;
GOSCISNSKI, 2011).
2.7.9 ALTA DISPONIBILIDADE E RECUPERAO DE DADOS
A alta disponibilidade de recursos de um gestor visa minimizar o tempo
de inatividade do aplicativo e evitar a interrupo dos negcios. Alguns
gestores realizam isso atravs de um mecanismo de failover4, que detecta a
falha de servidores fsicos e virtuais e reinicia as VMs em outros servidores
fsicos. Porm esse modelo de failover no funcionar para VMs de misso
crtica, em que essas precisam ser redundantes e sincronizadas. O backup de
dados em nuvens deve levar em conta o alto volume de dados, essas cpias
devem ser feitas com uma interferncia mnima no desempenho dos sistemas.
Neste sentido, alguns gestores devem oferecer mecanismos de proteo de
3 Service Level Management um contrato entre duas partes, geralmente entre empresas e prestadores de servios, que contm clusulas de nveis de servios que devem ser seguidas e
obedecidas com tempos predefinidos, garantindo a qualidade e no interrupo do item contratado. 4 Segundo Gomes (2012), O processo no qual uma mquina assume os servios de outra, quando
esta ltima apresenta falha, chamado failover. O failover pode ser automtico ou manual, sendo
o automtico o que normalmente se espera de uma soluo de Alta Disponibilidade..
28
dados que executam backups incrementais de imagens de VMs (BUYYA;
BROBERG; GOSCISNSKI, 2011).
2.8 PRINCIPAIS GESTORES DA COMPUTAO EM
NUVEM
Nesse tpico sero abordados alguns dos principais gestores de
infraestrutura virtual e suas caractersticas bsicas.
2.8.1 APACHE VCL
Segundo VLC (2012), o Apache VLC um laboratrio de computao
virtual, open-source utilizado para fornecer acesso remoto para um ambiente
de computao dedicado para o usurio final atravs de uma interface Web, foi
projetado em 2004 por pesquisadores da North Carolina State University, como
forma de proporcionar ambientes personalizados para usurios do laboratrio
de informtica.
Em resumo, Apache VCL oferece os seguintes recursos: controlador
multiplataforma, baseado no Apache/PHP5, portal Web e interface XML-RPC6,
suporte para hypervisor VMware (ESX, ESXi, e servidor), redes virtuais,
clusters virtuais, e reserva antecipada de recursos.
2.8.2 CITRIX ESSENTIALS
O Citrix Essentials designado para Microsoft Hyper-V fornece aos clientes
virtualizao de servidores com um conjunto de servios avanados de
gerenciamento de virtualizao, permitindo estender essas capacidades de
gerenciamento para o ambiente Windows Server 2008, ajudando a tornar o
Hyper-V e o System Center mais escalveis, gerenciveis e geis (CITRIX,
2012).
Segundo Buyya, Broberg e Goscisnski (2011), a ferramenta oferece os
seguintes recursos: controlador grfico Web, CLI (Command Line Interface),
5 Apache: servidor Web open-source e PHP (HyperText PreProcessor): linguagem de
programao destinada ao desenvolvimento de pginas Web. 6 XML-RPC: chamada de procedimento remoto que utiliza XML.
29
portal Web, e XML-RPC (eXtensible Markup Language Remote Procedure
Call), apoio para XenServer e Hyper-V; Armazenamento Citrix; redes virtuais;
alocao dinmica de recursos; trs nveis de alta disponibilidade (recuperao
pelo reincio da VM, recuperao ativando uma VM duplicada pausada e VM
duplicada rodando continuamente) e proteo de dados com o Citrix
Consolidated Backup.
2.8.3 EUCALYPTUS
Segundo Eucalyptus (2012), o Eucalyptus se concentra na construo de
nuvens IaaS. Ele foi desenvolvido com a inteno de fornecer uma
implementao open-source quase idntica em funcionalidade com a API do
Amazon Web Services. Portanto, os usurios podem interagir com uma nuvem
Eucalyptus usando as mesmas ferramentas que eles usam para acessar o
Amazon EC27.
Segundo Buyya, Broberg e Goscisnski (2011), ele tambm se distingue
de outras ferramentas, pois fornece uma nuvem de armazenamento emulando
a API do Amazon S38 para armazenar dados do usurio e imagens gerais da
VM. Em resumo, Eucalyptus oferece os seguintes recursos: administrao
Web; EC2 (SOAP, Query) e S3 (SOAP9, REST) CLI10 e interfaces Web, Xen,
KVM e VMWare backends; Amazon EBS11 compatveis com dispositivos de
armazenamento virtuais, interface com o EC2 da Amazon, redes virtuais.
2.8.4 NIMBUS3
O conjunto de ferramentas Nimbus construdo em cima do Globus
Framework. Ele fornece a maioria das caractersticas dos outros gestores como
uma API para acesso ao Amazon EC2 com suporte ao Xen. No entanto,
7 Amazon EC2: o EC2 (Elastic Compute Cloud) um servio que permite o usurio alugar os
recursos computacionais da Amazon e rodar mquinas virtuais sobre os centros de dados da
empresa (AMAZON, 2012A). 8 O Amazon Simple Storage fornece uma interface simples de servio Web que pode ser usada para
armazenar e recuperar qualquer quantidade de dados, a qualquer momento, de qualquer lugar na
Web. (AMAZON, 2012B) 9 SOAP (Simple Object Access Protocol) um protocolo simples para troca de informao entre
computadores, baseado no XML. 10
Command Line Interface uma interface de linha de comando para entrada e sada de dados. 11
O Amazon Elastic Block Store (EBS) fornece volume de armazenamento em bloco para
instncias do Amazon EC2. Os volumes Amazon EBS so armazenamentos fora da instncia que
30
distingue-se dos outros, fornecendo uma interface de acesso para o framework
Globus Web Services Resource (WSRF). Em resumo, Nimbus fornece as
seguintes caractersticas: baseado em Linux; EC2 (SOAP) e interfaces WSRF;
suporte a Xen e KVM (BUYYA; BROBERG; GOSCISNSKI, 2011).
2.8.5 OPENNEBULA
O OpenNebula um open-source rico em recursos para gestores de
nuvem. Ao todo, quatro APIs de programao esto disponveis: XML-RPC e
libvirt para interao local; um subconjunto de EC2 (consulta) e APIs da nuvem
OpenNebula para acesso pblico. Sua arquitetura modular e conectvel, o
mdulo principal orquestra os servidores fsicos e seus hypervisors, ns de
armazenamento e de rede. O mdulo Scheduler est encarregado de atribuir
os pedidos pendentes de VM para hosts fsicos, oferecendo alocao de
recursos dinmicos (OPENNEBULA, 2012B).
Segundo Buyya, Broberg e Goscisnski (2011), em resumo, OpenNebula
oferece os seguintes recursos: baseado em Linux; CLI, XML-RPC, EC2 e
OpenNebula Cloud API; Xen, KVM e VMware backend; interface para as
nuvens pblicas (Amazon EC2, ElasticHosts); redes virtuais; alocao dinmica
de recursos; reserva antecipada de capacidade.
2.8.6 OPENPEX
Segundo Venugopal et al. (2009), OpenPEX (Open Provisioning and
EXecution Environment) foi construdo em torno da noo de usar reservas
antecipadas como o principal mtodo para alocar instncias de VM. Distingue-
se de outros gestores, pois incorpora um protocolo de negociao bilateral que
permite usurios e provedores chegar a um acordo sobre troca de ofertas e
contra ofertas quando seus pedidos originais no podem ser satisfeitos.
Segundo Buyya, Broberg e Goscisnski (2011), em resumo, OpenPEX
oferece os seguintes recursos: multiplataforma (Java); portal Web e Web
Services (REST); Citrix Backend XenServer; reserva antecipada com
capacidade de negociao.
persistem independentemente da vida de uma instncia (AMAZON, 2012B).
31
2.8.7 OVIRT
Segundo OVIRT (2012), oVirt um gestor open-source, patrocinado pela
Red Hat Emergent. Ele fornece a maior parte das caractersticas bsicas dos
gestores, incluindo suporte para o gerenciamento de pools de servidores
fsicos, pools de armazenamento, contas de usurio e VMs. Todos os recursos
so acessveis atravs de uma interface Web, o n de administrao do oVirt,
que tambm uma VM, fornece um servidor Web, servios de autenticao
baseadas em FreeIPA (sistema integrado de segurana e gerenciamento de
informaes) e servios de provisionamento para gerenciar imagem de VM e
sua transferncia para os ns gerenciados.
Em resumo, oVirt oferece os seguintes recursos: baseado no Fedora
Linux, o controlador empacotado como um dispositivo virtual, interface Web;
KVM backend (BUYYA; BROBERG; GOSCISNSKI, 2011).
2.8.8 VMWARE VSPHERE
Segundo Buyya, Broberg e Goscisnski (2011), o VMWare vSphere uma
ferramenta destinada a transformar a infraestrutura em uma nuvem privada.
Distingue-se de outros gestores como um dos mais ricos em recursos. Na
arquitetura vSphere, servidores executam na plataforma ESXi. Um servidor a
parte executa vCenter Server, que centraliza o controle da infraestrutura.
Atravs do software cliente vSphere, os administradores conectam-se ao
vCenter Server para executar vrias tarefas. O Distributed Resource Scheduler
(DRS) toma decises de alocao com base em regras pr-definidas e
polticas. Ele monitora continuamente a quantidade de recursos disponveis
para VMs e, se necessrio, faz mudanas de alocao para atender aos seus
requisitos. VMFS vStorage um sistema de arquivos de cluster para agregar
vrios discos em um nico volume. VMFS especialmente otimizado para
armazenar imagens de VM e discos virtuais, suportando equipamentos que
utilizam Fibre Channel ou iSCSI SAN. O provisionamento de recursos aos
usurios finais fornecido atravs da API vCloud, que interage com o vCenter
Server. Nesta configurao, vSphere pode ser usado por prestadores de
servios para construir as nuvens pblicas.
Em resumo, vSphere oferece os seguintes recursos: baseado no
32
Windows (vCenter Server); CLI, GUI, Web portal, e interfaces de servios Web;
VMware ESX, ESXi backend; VMware; vStorage VMFS; interface para nuvens
externas (VMware vCloud); redes virtuais (VMware Distributed Switch);
alocao dinmica de recursos (VMware DRM); alta disponibilidade; proteo
de dados (VMware Consolidated Backup) (BUYYA; BROBERG; GOSCISNSKI,
2011).
2.8.9 OPENSTACK ESSEX
Segundo OpenStack (2012), o gestor oferece software para criar nuvens
pblicas e privadas. Contm uma coleo de projetos open-source, incluindo
OpenStack Compute (codinome Nova), armazenamento de objetos OpenStack
(codinome Swift), servio de imagem OpenStack (codinome Glance), servio
de armazenamento para uso das instncias (codinome Cinder) e servio de
rede (codinome Quantum). O OpenStack Essex fornece uma plataforma
operacional e um conjunto de ferramentas para gerenciamento das nuvens.
Em resumo o OpenStack Essex oferece gerenciamento do ciclo de vida
das instncias, gerenciamento dos recursos computacionais; rede e
autorizao; API REST; comunicao assncrona, suporte a mltiplos
hypervisors; Xen, XenServer/XCP, KVM, UML, VMware; vSphere e Hyper-V.
O OpenStack Essex, atualmente, um dos mais importantes gestores de
nuvem com a participao de mais de 200 empresas, incluindo a NASA, a qual
cedeu o cdigo-fonte do Nebula para construo da arquitetura.
As principais caractersticas dos gestores de nuvem so demonstradas na
Tabela 1, em que possvel notar as diferenas entre os gestores proprietrios
e open-source estudados nesse captulo.
33
TABELA 1 COMPARAO ENTRE OS GESTORES DE NUVEM.
Fonte: adaptado de Buyya, Broberg e Goscisnski (2011).
34
2.9 LIMITAES ENCONTRADAS COM OS GESTORES
Para um melhor entendimento do conceito e arquitetura da nuvem,
foram testados trs gestores, Eucalyptus (Apndice A - Instalao do
Eucalyptus), OpenNebula (Apndice B - Instalao do OpenNebula) e
OpenStack Essex (Apndice C - Instalao do OpenStack Essex), escolhidos
pela popularidade e por serem open-source. Nos testes foi verificado que os
gestores se comportam da mesma forma e possuem praticamente os mesmos
servios com algumas diferenas, na qual o OpenStack Essex mostrou melhor
eficincia, sendo assim, aqui ser demonstrada sua arquitetura e
funcionamento.
Aps a realizao de testes foi possvel levantar os principais problemas
da arquitetura open-source.
Failover: o Eucalyptus no tem failover, tanto para o gestor
quanto para o n. Por exemplo, se o gestor sofrer algum problema, os
ns continuaro funcionando normalmente, porm se o n apresentar
alguma indisponibilidade, a execuo daquela instncia ser perdida,
devendo um operador humano intervir, carregando a instncia em outra
VM, o mesmo foi observado com o OpenNebula e OpenStack Essex.
Segundo Chauhan et al (2012), uma soluo para contornar o problema
de indisponibilidade criar um sistema de cache para nuvem, conforme
Figura 7. Porm essa soluo aumentaria o consumo energtico, uma
das principais vantagens da Computao em Nuvem.
Algoritmo de Escalonamento: o Eucalyptus possui trs algoritmos
para escalonamento de instncias, o primeiro o ROUNDROBIN
(escolhe um n de cada vez), o segundo GREEDY (aloca a instncia no
primeiro n encontrado) e o terceiro o POWERSAVE (desliga os ns
que no esto executando instncias de mquinas virtuais), tanto o
OpenNebula quanto o OpenStack Essex tambm possuem algoritmos
locais similares. Nesse caso, o gestor poderia determinar de modo
eficiente e tcnico quem so seus ns e realizar o escalonamento de
acordo com o consumo da aplicao ou reescalonar caso perceba que
um n esteja excedendo quantidade utilizada de memria e CPU.
35
Distncias Geogrficas: no caso de nuvens geograficamente
distribudas, o gestor deveria conseguir reescalonar uma determinada
instncia de VM de acordo com a regio na qual tem mais acessos. Um
dos problemas de virtualizar uma aplicao, que na maioria das vezes
ela no est preparada para ser acessada atravs de uma rede, sendo
assim, acessar uma aplicao geograficamente distante, geraria custo e
consumo de banda.
Consumo Energtico: ns que no esto executando instncias
deveriam estar desligados ou colocados em baixo consumo energtico,
para isso, o gestor deve fornecer algoritmos de escalonamentos que
consigam ativar ou desativar ns de acordo com a demanda. No
Eucalyptus foi analisado que o algoritmo PowerSave realiza esse
procedimento.
Proteo de Dados: no Eucalyptus e em qualquer outra nuvem open-
source, no existe poltica e controle de backup. Outro problema
encontrado que a nuvem open-source utiliza de solues de terceiros
para armazenamento, como NFS ou SAN. Nesse caso garantir a
redundncia das informaes torna-se muito dispendioso para a rede,
que no mnimo dever trabalhar a 10 Gbps para ter um desempenho
considervel.
Figura 7 Modelo de nuvem utilizando cache.
Fonte: CHAUHAN et al., 2012.
36
2.10 CONSIDERAES FINAIS
Nesse captulo foram apresentados os gestores analisados em
laboratrio, Eucalyptus, Nebula e o OpenStack Essex. Dos trs gestores
estudados, o Eucalyptus e o Nebula contm as mesmas funcionalidades e
limitaes apresentadas na Seo 2.9. O OpenStack Essex foi o que
apresentou os melhores resultados com alguns pontos positivos como,
documentao completa, comunidade ativa, preocupao com correo de
bugs, instalao facilitada e uma variedade de imagens prontas para
instncias.
Os trs gestores apresentaram deficincias em disponibilizar recursos
para virtualizao de armazenamento, alta disponibilidade, recuperao de
dados e algoritmos alternativos para escalonamento de mquinas virtuais,
objeto desse estudo.
37
3 ESCALONAMENTO DE RECURSOS
Nesse captulo so analisados os principais algoritmos de
escalonamento e os algoritmos de escalonamento utilizados nos principais
gestores open-source da Computao em Nuvem (Eucalyptus, OpenNebula e
OpenStack Essex).
3.1 CONSIDERAES INICIAIS
Um dos problemas mais desafiadores da computao paralela e
distribuda conhecido como problema de escalonamento. O objetivo do
escalonamento determinar uma atribuio de tarefas a elementos de
processamento com o intuito de otimizar certos ndices de desempenho, como
tempo processamento, leitura e escrita em disco ou memria (EL-REWINI;
ABD-EL-BARR, 2005).
Deve-se ressaltar que existem duas espcies de escalonamento dentro
da arquitetura:
Escalonador do gestor: os algoritmos de escalonamento trabalham
com a finalidade de escalonar instncias de mquinas virtuais para ns
computacionais, responsveis pelo processamento.
Escalonador do hypervisor, dentro do n computacional: o
algoritmo de escalonamento est presente no sistema operacional da
mquina fsica, compartilhando o processamento entre seus processos.
Conforme pode ser observado na Figura 8, para uma nuvem IaaS que
utiliza o KVM como hypervisor, as instncias de mquinas virtuais so
carregadas no Linux como um processo normal de usurio. Nesse caso, o
escalonador padro do Linux que determinada a execuo das instncias,
conforme seu algoritmo de escalonamento.
38
Figura 8 Listagem de processos do KVM no Linux.
Fonte: Autor.
3.2 ESCALONAMENTO
Segundo Silva (2012), em sistemas que empregam a multiprogramao,
processos concorrem pelo processamento, em que se faz necessrio dividir o
tempo de execuo de cada um deles, sendo feito de duas maneiras:
escalonamento dos processos a curto prazo e escalonamento dos processos a
longo prazo. No caso do escalonamento dos processos a curto prazo, o
escalonador decide quando o processo ser criado. Ele pode esperar, por
exemplo, a carga de processamento da mquina diminuir para criar novos
processos.
Esse tipo de escalonamento pode no ser atraente para usurios que
esto esperando a efetivao daquele processo, ou no caso da nuvem,
usurios que esto esperando pela sua instncia de mquina virtual ou outro
servio.
Ainda segundo Silva (2010), no escalonamento de curto prazo, o
processo executado sempre que o processador ficar livre, nesse caso, o
escalonador requisitado com grande frequncia.
O escalonador caracteriza-se como um mecanismo de gesto, utilizado
para gerenciar de forma eficiente e eficaz o acesso aos recursos por seus
vrios consumidores. Segundo a Figura 9, este mecanismo constitudo por
trs componentes principais: consumidores, recursos e poltica (CASAVANT;
KUHL, 1988).
Entretanto, h duas propriedades que devem ser avaliadas em quaisquer
sistemas de escalonamento de recursos:
A gerncia de recursos deve satisfazer os consumidores;
Consumidores no devem ser prejudicados por problemas associados
39
ao uso do escalonador.
Figura 9 Sistema de escalonamento.
Consumidores
Escalonador
Poltica Recursos
Fonte: Adaptado de: CASAVANT; KUHL (1988).
Em relao s nuvens uma terceira propriedade deve ser adicionada para
satisfazer tambm os provedores de servios, que oferecem os servios aos
consumidores. Sendo assim:
A gerncia de recursos deve satisfazer os provedores de servios;
Para que essas duas propriedades (de consumidores e provedores de
servios) no se sobreponham, devem existir acordos de nvel de servios
entre elas, tambm conhecidos como SLAs. Esses acordos garantem que os
recursos estaro disponveis para os consumidores ou parte deles, no qual os
consumidores aceitam participar de um ambiente compartilhado ou no,
dependendo do tipo de acordo estabelecido.
3.3 TAXONOMIA DE ESCALONAMENTO
Casavant e Kuhl (1988), conforme Figura 10, criou uma taxonomia para
classificar os diferentes tipos de escalonamento, com o intuito de fornecer um
mecanismo para permitir comparaes entre trabalhos na rea da computao
distribuda de forma qualitativa ou em qualquer conjunto de sistemas de gesto
de recursos:
Local: atribuio de tarefas por slots de tempo para um nico
processador.
Global: incide em onde executar as tarefas em um conjunto de
processadores.
40
Esttico: tambm conhecida como programao determinstica, todas
as informaes sobre as tarefas a serem executadas e suas relaes
com outras tarefas so totalmente conhecidas antes da execuo do
programa (EL-REWINI; ABD-EL-BARR, 2005).
Figura 10 Taxonomia de Escalonamento.
Local
Esttico
Global
Fisicamente
distribudo
Fisicamente
No distribudo
Dinmico
No cooperativoCooperativo
timo Subtimo
heursticaaproximado
timo Subtimo
heursticaaproximado
Enumerativo
Teoria dos Grafos
Programao Matemtica
Teoria de Filas
Clustering
Gentico
Lista
Fonte: Adaptado de: CASAVANT (1988) apud RUSANOVA, KOROCHKIN (1999).
Dinmico: conhecido tambm como escalonamento no-determinstico,
algumas informaes podem no ser conhecidas antes da sua execuo
(EL-REWINI; ABD-EL-BARR, 2005).
timo: quando possvel determinar todas as informaes sobre a
tarefa, como por exemplo, custo de comunicao, de execuo e
dependncias de tarefas.
Subtimo: quando essas informaes sobre tarefa no so possveis
de determinar, porm encontra-se uma soluo aceitvel.
Aproximado: satisfeito quando encontrada uma boa soluo para
um determinado problema, ao invs de procurar uma soluo tima em
todo o conjunto de solues.
Heurstica: esto presentes nessa categoria os algoritmos que fazem as
suposies mais realistas a respeito das caractersticas dos processos e
de carga do sistema.
No distribudo: a responsabilidade do escalonamento de tarefas
41
reside em um nico processador.
Distribudo: o trabalho envolvido na tomada de decises deve ser
distribudo entre os processadores.
No cooperativo: processadores tomam decises individualmente,
independentes do efeito no resto do sistema.
Cooperativo: nesse caso, h uma cooperao entre os componentes
distribudos.
Existem ainda algumas classificaes de escalonamento que segundo
Casavant e Kuhl (1988), no se encaixam exclusivamente na taxonomia, mas
so importantes como descrevem um escalonador:
Adaptativo: quando os algoritmos e parmetros mudam dinamicamente
de acordo com o comportamento anterior para se ajustar as novas
condies do sistema.
No adaptativo: ocorre quando o mecanismo de controle no sofre
alterao, independente do comportamento do sistema.
Balanceamento de carga: tenta prover o equilbrio de carga entre os
processadores do sistema.
Bidding: nesse tipo de poltica, h uma cooperao entre os ns que
executaro as tarefas, no sentido de troca de informaes, conforme o
sistema cooperativo.
Probabilstico: analisar uma grande quantidade de tarefas antes de
escalonar pode resultar em uma perda de tempo por parte do
processador. Para compensar esse problema, processos so escolhidos
aleatoriamente, e entre esses processos, os que apresentam os
melhores resultados so escolhidos.
Existem diversas propriedades que podem fomentar um algoritmo de
escalonamento. Nessas condies torna-se essencial analisar e investigar
quais os objetivos que este deve possuir para atender um servio ou tarefa.
Atualmente, os algoritmos de escalonamento de nuvens open-source so
determinsticos, as informaes para determinar o n computacional com mais
recursos no levam em considerao as condies fsicas do n computacional
42
no momento do escalonamento.
Segundo Dandamudi (1994), o escalonamento de processos tem um
impacto substancial no desempenho quando as estratgias de escalonamento
no-adaptativo so utilizadas. Assim, se faz necessrio criar um escalonador
dinmico e adaptativo, onde segundo El-Rewini; Abd-El-Barr (2005), este
normalmente implementado como uma espcie de heurstica de
balanceamento de carga. Porm, alguns problemas devem ser verificados,
como a sobrecarga gerada para determinar o escalonamento enquanto o
programa est sendo executado ou como medir o custo de cada processo.
3.4 BALANCEAMENTO DE CARGA
O balanceamento de carga tem como caracterstica distribuir a carga de
trabalho entre vrios ns situados no cluster, com a finalidade de alcanar uma
utilizao simtrica ou ideal dos recursos, evitando sobrecarga de um ou mais
ns computacionais. Na nuvem, o balanceamento de carga tem uma funo
importante em que ajuda a garantir a qualidade de servios prestados aos
usurios em relao disponibilidade de recursos (SIDHU; KINGER, 2013).
3.4.1 CLASSIFICAO DOS ALGORITMOS DE BALANCEAMENTO DE CARGA
Segundo Sidhu e Kinger (2013), os algoritmos de balanceamento de
carga so divididos em duas principais categorias:
Dependendo da forma como a carga est distribuda e como os
processos so atribudos aos ns (carga do sistema):
o Centralizado: um nico n responsvel por gerenciar a
distribuio de carga;
o Distribudo: cada n independente e as decises so
tomadas localmente de acordo com as informaes de
cargas de outros ns.
o Mista: a combinao entre as duas formas anteriores.
Dependendo das informaes de estado dos ns (topologia do
sistema).
43
o Dinmico: leva em conta o estado atual do sistema durante
as decises de balanceamento;
o Adaptativo: nesse modelo, o balanceamento de carga se
adapta quando o estado do sistema muda, alterando seus
parmetros e at seus algoritmos de forma dinmica.
3.4.2 ALGORITMOS DE BALANCEAMENTO DE CARGA
Existem diversos algoritmos de balanceamento de carga propostos, Sidhu
e Kinger (2013) apontam os principais:
Connection Mechanism: nesse caso, o algoritmo de
balanceamento de carga determina a quantidade de conexo por
n e faz o balanceamento de acordo com esse nmero.
Randomized: nesse tipo, um processo pode ser tratado por um
determinado n n, com uma probabilidade p, para diferenciar
cargas de diferentes complexidades.
Equally Spread Current Execution Algorithm: nesse tipo, a
carga de mquinas sobrecarregas distribuda aleatoriamente
atravs da checagem da carga.
Throttled Load Balancing Algorithm: esse algoritmo voltado
para mquinas virtuais, em que solicitado ao balanceador
encontrar um n adequado para realizar a operao desejada.
Task Scheduling Algorithm Based on Load Balancing:
composto de um mecanismo de agendamento de tarefas em dois
nveis baseado em balanceamento de carga para atender s
necessidades dinmicas dos usurios e obter alta utilizao de
recursos.
Max-Min Algorithm: a mquina que possui o tempo mnimo de
concluso de todos os trabalhos selecionada.
Scheduling strategy on load balancing of virtual machine
resources: faz o balanceamento de processos utilizando dados
histricos e dados do estado atual do sistema para escalonar VMs
(KANSAL, CHANA, 2012).
44
Conforme analisado, h alguns algoritmos propostos para balanceamento
de carga de processos em sistemas distribudos. O gestor de nuvem, alm de
decidir sobre qual n dever alocar o novo pedido de instncia de VM, deve
tambm:
Ter a capacidade de redistribuir a carga do cluster, garantindo a
disponibilidade dos servios de usurios.
Ou realocar instncias para ns com capacidades de
processamento livre, desligando ns ociosos, ajudando na reduo
do consumo de energia e, consequentemente, na reduo de
emisso de carbono (KANSAL, CHANA, 2012).
3.4.3 MTRICAS PARA BALANCEAMENTO DE CARGA
Segundo Sidhu e Kinger (2013), existem alguns indicadores para
balanceamento de carga na nuvem que devem ser analisados:
Escalabilidade: a capacidade de executar um algoritmo para
equilbrio de carga de um sistema com um nmero finito de ns.
Utilizao de Recursos: utilizado para verificar a utilizao de
recursos. Ele deve ser otimizado para um balanceamento de carga
eficiente.
Desempenho: usado para verificar a eficincia do sistema. Deve
ser melhorado a um custo razovel, por exemplo, reduzir o tempo
de resposta de tarefas, mantendo atrasos aceitveis.
Tempo de Resposta: a quantidade de tempo necessrio para
responder atravs de um algoritmo de balanceamento de carga.
Sobrecarga Associada: determina a quantidade de sobrecarga
envolvida durante a implementao de um algoritmo de
balanceamento de carga. Essa sobrecarga gerada pelo
movimento de VMs e comunicao entre ns.
45
3.5 ESCALONAMENTO E BALANCEAMENTO NO
OPENSTACK
O OpenStack Essex implementa os algoritmos em linguagem Python,
sendo o binrio nova-scheduler, responsvel por calcular e decidir qual n
dever lanar uma instncia de imagem de mquina virtual, entre outras
responsabilidades.
A importncia do escalonador que em tais ambientes de nuvem, muitas
vezes h mais de um n para carregar uma instncia de imagem de mquina
virtual. Como gerenciar e medir esses ns um problema muito importante,
assim como reagir a um pedido de usurio para alocao da instncia tambm.
O nova-scheduler interage com outros componentes atravs de uma fila
(Queue) e nova-database (banco de dados do gestor), no caso do
agendamento, a fila o centro de comunicao. Todos os ns publicam
periodicamente o seu estado, os recursos disponveis e as capacidades de
hardware para nova-scheduler atravs da fila. Assim o nova-scheduler recolhe
esses dados e os utiliza para tomar decises, de acordo com as solicitaes de
recursos (OPENSTACK, 2012).
Filter Scheduler: segundo OpenStack (2012), O filter
(nova.scheduler.filter_scheduler.FilterScheduler) o agendador padro
para escalonar instncias de mquinas virtuais. Ele suporta filtragem e
ponderao para tomar decises de onde uma nova instncia dever ser
criada. Conforme pode ser observado na Figura 11, quando o
escalonador recebe um pedido de um recurso, primeiro aplica filtros para
determinar quais ns so elegveis para alocar uma instncia. Ns que
so aceitos pelo filtro so ento processados por um algoritmo diferente
para decidir qual alocar o pedido. Existem dezenas de filtros
preexistentes no OpenStack Essex, alguns realizando filtragem pela
quantidade de ncleos do processador, memria, rede entre outros
recursos presentes nos ns.
46
Figura 11 Seleo de ns nova-scheduler.
Fonte: OPENSTACK, 2012.
Custos e Pesos: o nova-scheduler seleciona os ns que permaneceram
aps a filtragem e aplica uma ou mais funes de custo para obter
pontuao numrica para cada n. Se houver mltiplas funes de
custo, as pontuaes so somadas. O escalonador seleciona o n que
tem o mnimo custo ponderado. De acordo com OpenStack (2012), o
gestor tem trs funes de custo:
o compute_fill_first_cost_fn_weight: esta funo de custo calcula a
quantidade de memria livre (RAM) disponvel no n.
o nova.scheduler.least_cost.retry_host_cost_fn: esta funo de
custo acrescenta um valor adicional para repetir o escalonamento
para um n que j foi usado para uma tentativa de agendamento
prvio.
o nova.scheduler.least_cost.noop_cost_fn: esta funo de custo
retorna 1 para todos os ns.
Outros Escalonadores: o gestor possui outros escalonadores que
atuam em conjunto com os filtros para escalonar instncias de mquinas
virtuais:
o Chance Scheduler (nova.scheduler.chance.ChanceScheduler):
seleciona aleatoriamente um n a partir de uma lista de anfitries
filtrados. o padro do gestor.
47
o Multi Scheduler (nova.scheduler.multi.MultiScheduler): contm
diversas sub-rotinas de programao para escalonamento de ns.
o padro de escalonamento de volumes no OpenStack Essex.
Agregadores de Ns: os agregadores dividem os ns em uma zona de
disponibilidade, para permitir uma programao avanada na criao de
pools de recursos ou para definir grupos lgicos para a migrao de ns.
3.6 CONSIDERAES FINAIS
Existem diversos algoritmos de escalonamento utilizados para
determinar um melhor balanceamento de processamento e distribuio de
recursos. Em nuvens open-source, os principais algoritmos so determinsticos,
utilizando da pontuao para determinar o n que ser utilizado para
processamento. Essa pontuao no leva em considerao as condies de
recursos disponveis na nuvem, podendo prejudicar seu desempenho e afetar
os servios entregues aos clientes pelos prestadores de servios.
O escalonador atual da OpenStack Essex utiliza o algoritmo roundrobin
para distribuir as instncias de VMs entre o ns da nuvem. Caso deseje
equilibrar essa carga, pesos so adicionados aos ns com mais recursos,
porm fica a critrio do operador decidir quais so esses ns.
Essa escolha pode influenciar diretamente no desempenho de uma VM,
devendo esta ser realizada por medies constantes e com base tcnica para
decidir o modo de balanceamento. Simplesmente atribuir um peso, pode no
ser a uma mtrica eficaz e que condiz com a realidade. Por esse motivo, o
algoritmo de escalonamento deve ser alimentado constantemente (feedback)
com a situao da nuvem, para determinar a forma como vai atribuir uma VM a
um determinado n.
48
4 METODOLOGIA E PROTTIPO
Nesse captulo apresentada a metodologia e um prottipo de um
algoritmo para escalonamento dinmico de instncias de mquinas virtuais na
nuvem.
4.1 CONSIDERAES INICIAIS
O objetivo desse captulo discutir um algoritmo de escalonamento para
nuvem e apresentar um algoritmo prottipo que seja capaz de verificar a carga
de cada n existente na nuvem privada, antes de alocar um pedido de instncia
de mquina virtual.
4.2 METODOLOGIA
Para o desenvolvimento desse trabalho foi construda uma nuvem.
Conforme Figura 12, foram utilizados quatro computadores fsicos, onde uma
mquina foi utilizada como gestor (responsvel por gerir a nuvem) e as demais
mquinas como ns computacionais (mquinas fsicas que abrigam e
processam as mquinas virtuais).
Figura 12 Escalonamento no gestor de nuvem.
Gestor
Ns Computacionais
Escalonamento
Nuvem
Instncia de VM
Fonte: Autor.
49
A Tabela 2 descreve a situao inicial de cada n, quantidade de
memria, rede, CPU, quantidade de ncleos e o cache de processador em
cada n fsico.
TABELA 2 ESPECIFICAES DOS NS.
Ns Escalonador Rede Memria CPU Mhz Cache Size Ncleo
N 01 Simple 100 Mbps 4 GB 2000 3073 KB 4
N 02 Simple 100 Mbps 4 GB 2000 3073 KB 4
N 03 Simple 100 Mbps 4 GB 2000 3073 KB 4
A Tabela 3 demonstra o estado inicial dos ns em relao aos recursos
disponveis antes do teste de escalonamento. Conforme Tabela 3, todos os ns
apresentam 99% de CPU disponvel (levando em considerao que cada
processador composto de quatro ncleos), 100% de disponibilidade de disco
e rede e mdia de 90% de disponibilidade de memria para alocao de
instncias de mquina virtual.
TABELA 3 RECURSOS DISPONVEIS ANTES DO TESTE.
Ns CPU % Rede % Memria % Disco %
N 02 99.75 100 91 100
N 03 99.875 100 91.2 100
N 04 99.875 100 90 100
Para uma melhor observao dos resultados e prover uma comparao
mais detalhada na fase de desenvolvimento, os algoritmos foram testados com
trs comportamentos de mquinas virtuais, na tentativa de simular um
ambiente real de produo.
4.2.1 COMPORTAMENTO 1: MQUINAS VIRTUAIS DE CONSUMO CONSTANTE COM CARGAS DISTANTES
Foram criadas trs imagens de mquina virtual com o sistema operacional
Ubuntu Server 12.04 em que na sua inicializao executado o programa
abaixo com um nmero diferente de threads para cada sistema operacional.
$threads = threads->new(\&stressDisk)
$threads = threads->new(\&stressNet)
$threads = threads->new(\&stressCPU)
50
Cada thread disparada pelo programa escrito em Perl, encontrado com
maiores detalhes no Anexo A test_node_fx.pl, fornece um consumo
constante de recursos (processamento, rede e disco) conforme Figura 13.
Figura 13 Sistemas operacionais virtualizados com cargas distantes.
Fonte: Autor.
O programa no precisou gerar um consumo para memria, pois quando
uma VM carregada, o gestor separa no sistema operacional hospedeiro a
quantidade de memria desejada. Nesse caso, foram criados perfis de
memrias dentro do gestor, especificando no script de lanamento o perfil
desejado para cada VM.
Figura 14 Perfis de memria.
Fonte: Autor.
Foram criados trs perfis de memria (tipo1, tipo2 e tipo3) cada um com,
respectivamente, 128MB, 192MB e 256MB de consumo. Aps os sistemas
operacionais com cargas diferentes foram carregados para o gestor, que os
disponibilizou para escalonamento como visto na
Figura 15.
51
Figura 15 Sistemas operacionais disponveis para o gestor.
Fonte: Autor.
Com as mquinas disponveis para escalonamento, o prximo passo foi
realizar os testes de escalonamento com o algoritmo atual do gestor
OpenStack Essex. Para incio do teste, foram lanadas oito instncias de
mquinas virtuais utilizando o programa abaixo que percorre um lao de um at
oito, selecionando aleatoriamente um dos trs sistemas operacionais criados
com cargas diferentes e a quantidade de memria de acordo com a mquina
selecionada.
Aps a execuo do programa, conforme pode ser observado pela Figura
16, os ns 1 e 2 so os que possuem mais recursos disponveis, porm o n 3
recebeu 4 instncias, sobrecarregando-o mais que os outros.
Figura 16 Teste de escalonamento comportamento 1: 08 instncias.
Fonte: Autor.
4.2.2 COMPORTAMENTO 2: MQUINAS VIRTUAIS DE CONSUMO CONSTANTE COM CARGAS APROXIMADAS
Para o teste com um segundo comportamento, foram criadas mquinas
virtuais com consumo em pequena escala e com valores aproximados. Esse
52
teste foi criado para ser possvel aumentar a quantidade de VMs escalonadas,
visto que existiu uma restrio com o hardware utilizado nesse laboratrio, em
que as quatro mquinas fsicas so de uso desktop e no servidores.
Figura 17 Sistemas operacionais virtualizados com cargas aproximadas.
Fonte: Autor.
Conforme Figura 17, a diferena de carga entre os sistemas operacionais
pequena, permitindo que uma mquina fsica abrigue mais instncias.
Aps executar o pedido de escalonamento para trinta instncias, foram
obtidos os resultados vistos na Figura 18, onde todos os ns receberam a
mesma quantidade de instncias, porm o n 02 teve seus recursos mais
esgotados que o n 1 e 3.
Figura 18 Teste de escalonamento comportamento 2: 30 instncias.
Fonte: Autor.
53
4.2.3 COMPORTAMENTO 3: MQUINAS VIRTUAIS DE CONSUMO VARIVEL
Nesse modelo de comportamento, foi criado um programa que fornece
um consumo varivel com o uso de threads que so disparados de modo
randmico, conforme pode ser observado com maiores detalhes no Anexo B
test_node_rand.pl.
O programa gera uma quantidade de perfis de consumo (CPU, memria,
disco e rede). Cada perfil inicia um novo thread com um determinado tempo de
vida. Aps o thread finalizar um novo programa iniciado refazendo todo o
processo.
Para facilitar a compreenso, foi criada a Figura 19, onde inicialmente o
programa inicia de 1 a 10 threads e cada um desses threads iniciam de 1 a 3
novos threads contendo um consumo especfico: CPU, disco e rede. Cabe
ressaltar novamente que a memria no foi inserida na seleo, pois quando
uma instncia de mquina virtual carregada, o KVM retira a poro de
memria disponvel da mquina fsica e aloca para a mquina virtual.
Figura 19 Programa de simulao de consumo varivel.
Processo
Start_Stress
Processos
Mltiplos
Processos
Mltiplos
Uso de CPU
Processos
Mltiplos
Uso de REDE
Processos
Mltiplos
Uso de DISCO
Cada subprocesso inicia com 1
a 3 procedimentos (Disco, CPU e
Rede) (rand)
O processo Start inicia
com 1 a 10 filhos (rand)
Cada procedimento de
teste iniciado com um
tempo de vida
randmico
O processo reinicia a
partir do momento da
morte dos subprocessos
O procedimento entra
em loop at seu tempo
de vida randmico
terminar
Fonte: Autor.
54
Aps criar o sistema operacional virtualizado contendo o programa que
gera o consumo aleatrio, foram realizados oito escalonamentos de instncias
de mquinas virtuais.
Figura 20 Teste de escalonamento comportamento 3: 08 instncias.
Fonte: Autor.
Conforme Figura 20, foram realizados medies aleatrias nos primeiros
dez minutos, vinte minutos, trinta minutos e uma hora. Ocorreram variaes de
consumo de recursos, porm essas variaes seguiram um padro, permitindo
estipular por mdia, a quantidade disponvel de recursos dos ns.
4.3 O PROTTIPO
A nuvem possui um gestor de infraestrutura que conta com um
escalonador de recursos. Diferentemente de um sistema operacional que,
geralmente, lida com processos de baixa granularidade, o gestor da nuvem lida
com instncias de mquinas virtuais, se comparativamente a processos, pode-
se dizer de alta granularidade. Assim, o escalonador da nuvem IaaS lida com
pedido de alocao de instncias de mquinas virtuais, devendo este
determinar em qual n alocar essa instncia.
Em contrapartida de um processo comum de escalonamento, na nuvem a
instncia de mquina virtual permanece ativa, consumindo recursos ou no, at
que uma ao (pedido do usurio ou falha hardware/software) interrompa seu
processamento. Alguns itens devem ser avaliados antes do escalonador de
nuvem tomar sua deciso sobre qual n dever alocar um novo pedido de
55
recursos, tais como:
Capacidade livre de processamento do n;
Quantidade de memria total disponvel;
Quantidade de memria secundria disponvel;
Capacidade livre de leitura/gravao da memria secundria;
Capacidade livre de upstream e downstream da rede;
Um dos principais problemas de escalonamento determinar o custo de
uma tarefa. Na nuvem encontra-se o mesmo problema de como determinar o
custo de processamento, disco, memria e rede de uma instncia de mquina
virtual antes de ser escalonada. Nesses casos prope-se utilizar um esquema
adaptativo, em que os algoritmos e os parmetros utilizados para decises de
escalonamento mudam dinamicamente de acordo com o estado de recurso
anterior, corrente e/ou futuro (DONG;AKL, 2006).
Conforme pode ser observado na Figura 21, na computao em Grid que
de certa forma torna-se similar com a nuvem, o escalonamento adaptativo
realizado com foco na heterogeneidade dos recursos de candidatos, o
dinamismo do desempenho dos recursos, bem como a diversidade de
aplicaes (DONG;AKL, 2006):
Figura 21 Taxonomia de escalonamento em Grid.
Escalonamento Adaptativo
Adaptao do Desempenho Dinmico
Adaptao dos Recursos
Adaptao da Aplicao
Fonte: DONG;AKL, 2006.
Segundo Casavant e Kuhl (1988), uma suposio de uma boa soluo de
escalonamento pode ser reconhecida nos casos em que est disponvel uma
mtrica para avaliar uma soluo, esta tcnica pode ser utilizada para diminuir
o tempo necessrio para encontrar uma soluo aceitvel (programao). Os
fatores que determinam esta abordagem incluem:
56
A disponibilidade de uma funo para avaliar uma soluo.
O tempo necessrio para avaliar uma soluo.
A capacidade de julgar de acordo com algumas mtricas o valor de
uma soluo tima.
A disponibilizao de um mecanismo de inteligncia para limitar o
espao solues.
Para um ambiente de nuvem, o escalonador precisa avaliar as condies
dos ns computacionais (aproximado ou heurstico) antes de alocar a prxima
instncia de mquina virtual (escalonamento esttico), dever selecionar o n
com mais recursos disponveis, considerando que no possvel medir com
preciso a quantidade de recursos que a nova instncia necessitar
(subtimo), medir periodicamente (adaptativo) e realocar as instncias se
necessrio (balanceamento de carga), para no prejudicar o desempenho das
demais instncias presentes no n em questo.
O algoritmo proposto constitudo de duas partes:
A primeira deve avaliar constantemente os recursos livres de cada
n e guardar as informaes.
A segunda deve selecionar o n com mais recursos no momento
da instanciao de mquina virtual.
Assim, o algoritmo deve monitorar a quantidade livre de recursos em cada
n da nuvem privada, criar um ndice para o gestor com os ns com mais
recursos disponveis e escalonar para ns com mais recursos, novas
solicitaes de instncias de mquinas virtuais. Para que esse objetivo fosse
atingindo, foi necessrio dividir o algoritmo em dois mdulos, um presente no
gestor e o outro presente nos ns.
4.3.1 RECURSOS DOS NS
Foi criado um programa que monitora, em intervalos de tempo
predefinidos a quantidade de recursos de cada n (Anexo C
node_resources.py). Esse programa possui duas importantes funes:
resources: essa funo executada apenas uma vez (quando o
n iniciado) e atravs de anlises de desempenho, determina
57
quais as capacidades mximas de transferncia de dados do disco
e da rede, quantidade de ncleos no processador, processamento
e memria disponvel.
check_node: essa funo executada a cada cinco minutos
armazenando em banco a quantidade de recursos disponveis do
n.
O programa est presente em cada n da nuvem e foi escrito em Python
por ser a mesma linguagem utilizada pelo OpenStack Essex. Antes de executar
as duas funes citadas acima, inicialmente o programa utiliza da funo def
check_net_velocity para analisar a taxa de transferncia da bridge, necessria
para comunicao entre ns e gestor e a funo def check_disk_velocity para
determinar a capacidade de leitura e gravao de disco. Essa anlise ocorre
apenas uma vez, quando a mquina fsica ligada e o sistema operacional
iniciado. Uma vez calculado esses parmetros, no se faz necessrio analisa-
los novamente.
No caso especfico do disco, para determinar a sua velocidade, feito um
teste de gravao e leitura para calcular as taxas de transferncias. O valor
referente a sua taxa de transferncia foi armazenado em arquivo para no
prejudicar a aferio dos recursos utilizados pelo n, visto que h um consumo
elevado justamente no momento de determinar sua taxa. Assim, esse processo
ocorre uma vez quando o sistema operacional da mquina fsica iniciado.
Aps verificadas as capacidades de rede e disco, a funo def
resources informa para a funo def check_node todos os recursos utilizados
pelo n, importantes para determinar o escalonamento. Para isso, foi
necessria uma biblioteca do Python chamada PSUTIL, essa biblioteca contm
funes que avaliam o uso de recursos como CPU, memria, rede e disco.
A funo def check_node recebe por parmetro os dados contendo o
consumo atual do n e atravs de operaes simples, so calculadas
porcentagens das quantidades livres de recursos para CPU, memria, disco e
rede de acordo com a capacidade mxima do n.
Com os resultados estabelecidos, as informaes so armazenadas em
um banco de dados, conforme estrutura apresentada na Figura 22.
58
Figura 22 Tabela de armazenamento das informaes dos ns.
Fonte: Autor.
O algoritmo foi agendado para executar a cada cinco minutos. Esse
tempo foi baseado no comando uptime, presente em sistemas Linux e Unix,
que verifica a carga de processos nesses sistemas, conforme o ltimo registro
da Figura 23.
Figura 23 Agendamento de execuo de programa (crontab).
Fonte: Autor.
59
4.3.2 ESCOLHA DOS NS
O segundo algoritmo est inserido no gestor. Este deve capturar todos os
registos inseridos no banco de dados