Escalonamento em CLOUD

Naylor Garcia Bachiega

Algoritmo de Escalonamento de Instncia de Mquina Virtual na

Computao em Nuvem

So Jos do Rio Preto 2014


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


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


4 METODOLOGIA E PROTTIPO ................................................................ 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


5 CONCLUSO ............................................................................................. 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;


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;


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


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.


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



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.


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.


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

Documents

Escalonamento em CLOUD