of 106 /106
Avaliação de roteamento em redes P2P visando obtenção de QoS na busca de serviços em nuvem Dionisio Machado Leite Filho

Avaliação de roteamento em redes P2P visando obtenção de ... fileobtenção de QoS na busca de serviços em nuvem ... ICMC-USP, como parte ... Qualidade de Serviço. 3. Metaescalonadores

Embed Size (px)

Text of Avaliação de roteamento em redes P2P visando obtenção de ... fileobtenção de QoS na busca de...

Avaliao de roteamento em redes P2P visando obteno de QoS na busca de servios em nuvem

Dionisio Machado Leite Filho

Avaliao de roteamento em redes P2P visando obteno de QoS na busca de servio em nuvem

Dionisio Machado Leite Filho

Orientadora: Profa. Dra. Regina Helena Carlucci Santana

Dissertao apresentada ao Instituto de Cincias Matemticas e de Computao - ICMC-USP, como parte dos requisitos para obteno do ttulo de Mestre em Cincias - Cincias de Computao e Matemtica Computacional. VERSO REVISADA

USP So Carlos

Maio de 2012

SERVIO DE PS-GRADUAO DO ICMC-USP

Data de Depsito: Assinatura:________________________

Ficha catalogrfica elaborada pela Biblioteca Prof. Achille Bassi e Seo Tcnica de Informtica, ICMC/USP,

com os dados fornecidos pelo(a) autor(a)

L533aLeite, Dionisio Machado Avaliao de roteamento em redes P2P visandoobteno de QoS na busca de servio em nuvem /Dionisio Machado Leite; orientadora Regina HelenaCarlucci Santana. -- So Carlos, 2012. 106 p.

Dissertao (Mestrado - Programa de Ps-Graduao emCincias de Computao e Matemtica Computacional) --Instituto de Cincias Matemticas e de Computao,Universidade de So Paulo, 2012.

1. Avaliao de Desempenho. 2. Qualidade deServio. 3. Metaescalonadores. 4. P2P. 5. Simulao.I. Santana, Regina Helena Carlucci, orient. II.Ttulo.

Agradecimentos

A gradeo primeiramente aos meus pais que sempre me motivam e incentivam tanto nosmomentos felizes como nos momentos tristes. professora Regina, minha orienta-dora, por ter aceitado me orientar e ter me guiado nos momentos em que eu necessitavae pela pacincia em me orientar. Agradeo tambm os professores que contriburam com a mi-nha formao, em especial ao professor Marcos Santana que me deu conselhos valiosos nocomeo da minha pesquisa.

Aos meus amigos de repblica (Fabio, Stnio, Daniel, Koxonha) que me deram um apoiomuito grande tanto nas dificuldades como nas alegrias.

Aos amigos de laboratrio que me aguentam toda semana (Paulo, Bruno, Daniel, Fausto,Edvard, Roni, Edwin, Luis e os demais que esto chegando ou saindo) e ainda contribuem paradiscusses interessantes no s sobre trabalho mas tambm discusses do dia-a-dia.

Agradeo ao Maycon que, alm de ser um amigo, me deu um apoio fundamental no iniciodo meu mestrado e sempre esteve a disposio para discutir possveis melhorias relacionadasao meu trabalho.

Agradeo ao professor Julio pelas contribuies sempre bem vindas e pelas contribuiesque ainda esto por vir.

Agradeo ao ICMC e principalmente ao LASDPC por proporcionar uma estrutura na qualeu pude crescer tanto como pessoa tanto como profissional.

i

Resumo

E ste trabalho apresenta a avaliao de diferentes algoritmos de ro-teamento utilizados na camada lgica ponto a ponto (P2P) ado-tada por um Metaescalonador que prov Qualidade de Servios(QoS) na Computao em Nuvem. Experimentos mostram a superiori-dade de trs algoritmos de roteamento P2P (BCR, Chord e Pastry) emrelao utilizao de Round Robin, analisando-se o tempo de respostae a variabilidade entre os resultados obtidos em diferentes testes. Os ex-perimentos consideram, alm dos algoritmos de roteamento, a influnciado nmero de usurios e do tipo de servio requisitado e como essesfatores interagem entre si. apresentado ainda um estudo sobre a me-lhor mtrica a ser adotada para representar as informaes da rede. Asmtricas consideradas foram latncia e nmero de saltos. Os resultadosobtidos permitem determinar, com base nos objetivos especificados, qualo impacto dos sistemas P2P utilizados pelo metaescalonador na busca edescoberta de servios em relao forma como a qualidade de servios abordada.

iii

Abstract

T his work presents an evaluation of different routing algorithmsthat are employed in a logical layer peer-to-peer (P2P) that areadopted by a Metascheduler that provides quality of services (QoS)in Cloud Computing. The experiments show the superiority of three P2Prouting algorithms (BCR, Chord, Pastry) in relation to Round Robin utili-zation, analysing the response times and the variation between the resultsobtained results in different tests. The experiments consider, besides therouting algorithms, the influence of the number of the users and the typeof requested services and how these factors interact between themselves.Besides of this, it is presented a study about the better metric to be adop-ted to represent the network information. The considered metrics werethe latency and number of hops. The obtained results allow to determine,based on specific objectives, the impact of the utilization of P2P systemsby the metascheduler in the search and discovery of services in relationto the way that the QoS is performed.

v

Sumrio

Resumo iii

Abstract v

Lista de Siglas xiii

1 Introduo 11.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivao e Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Computao em Nuvem 52.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Virtualizao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Modelo Econmico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Caractersticas da Computao em Nuvem . . . . . . . . . . . . . . . . . . . . 82.5 Tipos de Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6 Provedores de Computao em Nuvem . . . . . . . . . . . . . . . . . . . . . . 102.7 Desafios da Computao em Nuvem . . . . . . . . . . . . . . . . . . . . . . . 122.8 Plataforma de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.8.1 CloudSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.8.2 Brite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.9 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Metaescalonadores 193.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Escalonadores Locais e Metaescalonadores . . . . . . . . . . . . . . . . . . . 203.3 MACC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.4 Qualidade de Servio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.5 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Comunicao nas Nuvens 274.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Descoberta de Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3 P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

vii

4.3.1 Caractersticas dos Sistemas P2P . . . . . . . . . . . . . . . . . . . . . 294.3.2 Redes de Sobreposio . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.4 Roteamento P2P em Sistemas Distribudos . . . . . . . . . . . . . . . . . . . . 324.5 Modelo de Comunicao do MACC . . . . . . . . . . . . . . . . . . . . . . . 344.6 Qualidade de Servio em Nvel de Rede . . . . . . . . . . . . . . . . . . . . . 364.7 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5 Desenvolvimento do Projeto 395.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2 Modelagem da Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.3 Projeto e Implementao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4 Algoritmos de Roteamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.4.1 Pastry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.4.2 Chord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.5 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6 Resultados 516.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.2 Seleo da Mtrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.3 Planejamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.4 Comparao entre as Polticas de Roteamento . . . . . . . . . . . . . . . . . . 59

6.4.1 Poltica Round Robin e Poltica BCR . . . . . . . . . . . . . . . . . . 596.4.2 Poltica Chord e Poltica BCR . . . . . . . . . . . . . . . . . . . . . . 646.4.3 Poltica Pastry e Poltica BCR . . . . . . . . . . . . . . . . . . . . . . 67

6.5 Poltica Pastry e Poltica Chord . . . . . . . . . . . . . . . . . . . . . . . . . . 706.6 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7 Concluses 757.1 Consideraes Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.2 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767.3 Dificuldades Relacionadas ao Projeto . . . . . . . . . . . . . . . . . . . . . . 777.4 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

viii

Lista de Figuras

2.1 Ambiente de nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Camadas da Arquitetura em Nuvem. Adaptado de Rimal et al. (2009). . . . . . 82.3 Formas de Desenvolvimento da Nuvem. Adaptado de (Furht, 2010) . . . . . . 92.4 Arquitetura do Simulador. Adaptado de (Calheiros et al., 2010) . . . . . . . . 142.5 Mdulos que Compe o BRITE. Adaptado de (Medina et al., 2001) . . . . . . 16

3.1 Modelo Centralizado de Troca de Informaes . . . . . . . . . . . . . . . . . . 213.2 Modelo Descentralizado de Troca de Informaes . . . . . . . . . . . . . . . . 213.3 Modelo de Troca de Mensagens Hierrquicas . . . . . . . . . . . . . . . . . . 223.4 Arquitetura do MACC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1 Taxonomia das Redes P2P. Adaptado de Ranjan et al. (2006) . . . . . . . . . . 294.2 Espao de Busca da CAN. Adaptado de Ratnasamy et al. (2002). . . . . . . . . 314.3 Espao de Busca do Chord. Adaptado de Stoica et al. (2001). . . . . . . . . . . 314.4 Espao de Busca do Pastry. Adaptado de Rowstron e Druschel (2001). . . . . . 324.5 Viso Geral do Modelo de Comunicao Adotado pelo do MACC. . . . . . . . 354.6 Modelo de Comunicao do MACC. . . . . . . . . . . . . . . . . . . . . . . . 35

5.1 Modelo Topolgico Utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2 Distribuio Geogrfica dos data centers . . . . . . . . . . . . . . . . . . . . . 415.3 Rede Utilizada nos Experimentos com 30 Clientes e 15 data centers . . . . . . 425.4 Rede Utilizada nos Experimentos com 60 Clientes e 15 data centers . . . . . . 425.5 Diagrama das Classes Utilizadas (Calheiros et al., 2010). . . . . . . . . . . . . 435.6 Fluxo de Comunicao Utilizado pelo CloudSim. Adaptado de Calheiros et al.

(2010). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.7 Busca Utilizando Round Robin . . . . . . . . . . . . . . . . . . . . . . . . . . 465.8 Busca Utilizando BCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.9 Topologia Pastry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.10 Busca Utilizando Pastry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.11 Topologia Chord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.12 Busca Utilizando Chord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.1 Diferena nos Tempos de Resposta . . . . . . . . . . . . . . . . . . . . . . . . 536.2 Distribuio dos Tempos de Resposta . . . . . . . . . . . . . . . . . . . . . . 546.3 Influncia dos Fatores na Varivel de Resposta. . . . . . . . . . . . . . . . . . 546.4 Diferena nos Tempos de Resposta (poltica Chord). . . . . . . . . . . . . . . 55

ix

6.5 Distribuio dos Tempos de Resposta em relao s Rplicas . . . . . . . . . . 556.6 Influncia dos Fatores no Segundo Experimento. . . . . . . . . . . . . . . . . 566.7 Diferena nos Tempos de Resposta (poltica Pastry). . . . . . . . . . . . . . . . 566.8 Distribuio dos Tempos de Resposta em relao s Rplicas . . . . . . . . . . 576.9 Influncia dos Fatores no Segundo Experimento. . . . . . . . . . . . . . . . . 576.10 Tempos de tomada de deciso dos algoritmos. . . . . . . . . . . . . . . . . . . 586.11 Histograma dos Tempos de Resposta. . . . . . . . . . . . . . . . . . . . . . . 616.12 Intervalos de Confiana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616.13 Grfico de Valores Individuais. . . . . . . . . . . . . . . . . . . . . . . . . . . 626.14 Influncia dos Fatores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.15 Principais Efeitos no Tempo de Resposta. . . . . . . . . . . . . . . . . . . . . 636.16 Interao entre os Fatores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 636.17 Histograma com os Tempos de Resposta (Chord e BCR). . . . . . . . . . . . . 646.18 Intervalos de Confiana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.19 Tempos de Resposta Individuais. . . . . . . . . . . . . . . . . . . . . . . . . . 656.20 Influncia dos Fatores nos Experimentos (Chord e BCR). . . . . . . . . . . . . 666.21 Efeitos dos Fatores nos Tempos de Resposta. . . . . . . . . . . . . . . . . . . 666.22 Interao dos Fatores (Chord e BCR). . . . . . . . . . . . . . . . . . . . . . . 676.23 Histograma com os Tempos de Resposta (Pastry e BCR). . . . . . . . . . . . . 686.24 Intervalos de Confiana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.25 Tempos de Resposta Individuais (Pastry e BCR). . . . . . . . . . . . . . . . . 686.26 Influncia dos Fatores nos Experimentos (Pastry e BCR). . . . . . . . . . . . . 696.27 Efeitos dos Fatores nos Tempos de Resposta (Pastry e BCR). . . . . . . . . . . 696.28 Interao dos Fatores (Pastry e BCR). . . . . . . . . . . . . . . . . . . . . . . 696.29 Histograma com os Tempos de Resposta. . . . . . . . . . . . . . . . . . . . . 706.30 Intervalos de Confiana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.31 Influncia dos Fatores nos Experimentos. . . . . . . . . . . . . . . . . . . . . 716.32 Efeitos dos Fatores nos Tempos de Resposta. . . . . . . . . . . . . . . . . . . 726.33 Interao dos Fatores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

x

Lista de Tabelas

2.1 Comparao das Ofertas Comerciais . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Comparao entre Metaescalonadores . . . . . . . . . . . . . . . . . . . . . . 25

6.1 Fatores Fixos definidos para todos os Experimentos . . . . . . . . . . . . . . . 526.2 Fatores Variveis (1o Experimento) . . . . . . . . . . . . . . . . . . . . . . . 536.3 Planejamento de Experimentos (RR e BCR) . . . . . . . . . . . . . . . . . . . 606.4 Planejamento de Experimentos (Chord e BCR) . . . . . . . . . . . . . . . . . 646.5 Planejamento de Experimentos (Pastry e BCR) . . . . . . . . . . . . . . . . . 676.6 Planejamento de Experimentos (Chord e Pastry) . . . . . . . . . . . . . . . . . 70

xi

Lista de Siglas

API - Application Programming InterfaceAS - Autonomous System

AWS - Amazon Web ServicesBCR - Baseada na Capacidade da RedeBoT - Bag of Task

CAN - Content Addressable NetworkCASA - Community Aware Scheduling Algorithm

CDN - Content Delivery NetworkCPU - Central Processing UnitDNS - Domain Name ServiceEC2 - Elastic Compute CloudGB - GigabyteGb - Gigabit

GRIS - General Resource Information SystemIaaS - Infrastructure as a Service

IP - Internet ProtocolLAN - Local Area Network

LRAM - Local Resource of Allocation ManagementLRMS - Local Resource Management SystemMACC - Metascheduler Architecture to provide QoS in Cloud Computing

MIPS - Million of Instructions Per SecondMSDN - Monitoring and Discovery System Manager

NIST - National Institute of Standards and TecnologyNWIRE - Net-Wide-Resources

PaaS - Platform as a ServiceQoS - Quality of Services

RAM - Random Access MemoryRR - Round Robin

SaaS - Software as a ServiceSGBD - Sistema de Gerenciamento de Banco de Dados

SLA - Service Level AgreementSLS - Service Location ServiceTCP - Transmission Control Protocol

TI - Tecnologia da InformaoUDDI - Universal Description, Discovery and Integration

VM - Virtual Machine

xiii

xiv

CAPTULO

1Introduo

1.1 Consideraes Iniciais

Nos ltimos anos, a forma como as aplicaes e servios so ofertados aos consumidoresvem passando por mudanas significativas. Antes da concepo dos sistemas que utilizam arede para o compartilhamento de recursos, para acessar um conversor de arquivos ou mesmoum editor de texto, os usurios precisavam realizar instalaes locais desses aplicativos.

Uma mudana relacionada a esse cenrio refere-se a utilizao de redes locais (LANs) quepermitem que programas possam ser acessados a partir de outros computadores sem a necessi-dade de instalao e configurao em todos os computadores participantes da rede. Esse foi umdos primeiros passos para a adoo de sistemas distribudos para o compartilhamento de dadose recursos entre computadores (Tanenbaum, 2003).

Um modelo de sistemas distribudos mais utilizado para o compartilhamento e processa-mento de servios o modelo cliente-servidor, onde um ou mais computadores com maior ca-pacidade tem a finalidade de armazenar, processar e prover acesso aos dados e servios (Kuroseet al., 2010).

Com o surgimento da World Wide Web (Berners-Lee, 2001) os sistemas cliente e servidorpassaram a ser cada vez mais utilizados e a partir dessa evoluo surgiram novas formas deoferecimento de servios como os portais Web e correios eletrnicos (e-mail) (Kurose et al.,2010).

Uma evoluo dos sistemas oferecidos sobre a Web foi o surgimento da computao emnuvem, onde o fornecimento de recursos e servios feito atravs da Internet e os usurios

1

2 1.1. CONSIDERAES INICIAIS

necessitam, na maior parte das vezes, utilizar um navegador Web para acessar servios e dadosque so armazenados e processados na nuvem (Armbrust et al., 2009).

A computao em nuvem uma forma de utilizar recursos computacionais, tais como, me-mria, aplicativos, processadores e etc. como servios. A forma de funcionamento da nuvem,se assemelha aos sistemas operacionais de rede (Wu et al., 2010), onde os recursos computa-cionais so fornecidos como um servio regular. A diferena entre a computao em nuveme sistemas operacionais de rede no o objetivo mas sim as tecnologias que se uniram pararealizar a formao da nuvem (Buyya et al., 2010).

De uma maneira geral, a computao em nuvem favorece a migrao dos servidores dedentro de uma empresa para uma nuvem. Os requisitos necessrios para o desenvolvimento deuma infraestrutura ou de um servio so definidos e o fornecedor de servios em nuvem criaessa infraestrutura (Zhang et al., 2010).

Com a migrao para a nuvem os custos ficam relacionados apenas aos recursos que soutilizados, o que caracteriza o modelo pague o que utilizar. Esse modelo de negcios visareduzir os preos com infraestrutura e manuteno de equipamento uma vez que os gastos commanuteno ficam a cargo dos provedores da computao em nuvem (Gupta, 2010). Com isso,uma das vantagens da computao em nuvem, alm da reduo dos preos, a possibilidadede aumentar a capacidade de seus servidores de acordo com o aumento da demanda de seusservios (Zhang et al., 2010).

No entanto, para a utilizao da nuvem, necessrio que existam mecanismos de monitora-mento para auxiliar no fornecimento e descoberta de servios para os usurios. Devido a essanecessidade, Peixoto et al. (2010) prope um metaescalonador que auxilia o monitoramento eentrega de servios aos usurios da computao em nuvem com qualidade de servio (QoS).

Qualidade de Servio (QoS) pode ser definida como a percepo do usurio em relao eficincia de um dado servio. QoS significa prover algum tipo de garantia sobre um ser-vio, tal como: perdas mnimas, desempenho mximo, pequeno tempo de resposta, exatido econsistncia dos dados recebidos (Vasiliou, 2000). Dentre essas caractersticas, o metaescalo-nador proposto utiliza o fornecimento de baixos tempos de resposta como garantia de QoS nacomunicao entre nuvens.

O metaescalonador tem como objetivo realizar a manuteno dos critrios de QoS, fazendocom que os servios sejam entregues de forma transparente aos clientes. Por se preocuparcom a qualidade de servio fim-a-fim, o metaescalonador proposto por Peixoto et al. (2010),auxilia em prover QoS na execuo das requisies dos usurios e na entrega dos servios. Ometaescalonador, para realizar a entrega e a descoberta de recursos, prope a utilizao de ummodelo de comunicao que utiliza sistemas P2P para o fornecimento de QoS fim-a-fim.

Esse metaescalonador desenvolvido de forma modular e dentre os seus mdulos est oescalonamento. No mdulo de escalonamento esto os escalonadores locais e as polticas deroteamento que so utilizadas por esse metaescalonador em sua camada de comunicao.

CAPTULO 1. INTRODUO 3

Sendo assim, este projeto de mestrado visa a avaliar essa camada de comunicao do meta-escalonador e a partir de metodologias de avaliao de desempenho determinar quais as vanta-gens da adoo dos sistemas P2P na obteno de QoS na computao em nuvem.

1.2 Motivao e Objetivos

A motivao para a proposta desse projeto de mestrado foi verificar que h vrios trabalhoscom foco na definio dos conceitos relacionados computao em nuvem e em como os ser-vios so executados. Jones (2008), Rimal et al. (2009), Armbrust et al. (2009), Furht (2010),Zhang et al. (2010), Mell e Grance (2011) entre outros, se preocupam em definir quais so ascaractersticas, funes e lacunas apresentadas pela computao em nuvem.

Trabalhos como os apresentados por Li et al. (2009), You et al. (2009), Li (2009) entreoutros, tem o objetivo de analisar as cargas de trabalho e como as formas de virtualizao soaplicadas na nuvem. Como o ambiente est na Internet, um dos pontos a ser analisado acomunicao entre os clientes dos servios disponibilizados pela nuvem. Graffi et al. (2010),Lai et al. (2010), Ranjan et al. (2010) e Zhou et al. (2011) apresentam conceitos relacionados busca de servios utilizando sistemas P2P.

Apesar de haver estudos relacionados comunicao entre as nuvens e utilizao de siste-mas P2P, no existe uma avaliao de desempenho que demonstre a razo da seleo de umsistema P2P (Pastry e/ou Chord) em detrimento de outro e muito menos como feita a inte-grao entre esses sistemas e as demais funcionalidades oferecidas pela nuvem para auxiliar naobteno de QoS.

O objetivo deste trabalho de mestrado avaliar os sistemas P2P que podem ser utilizadospara a descoberta de servios e levantar quais so suas vantagens e desvantagens dependendo dodomnio da aplicao que est sendo avaliada e como os sistemas P2P contribuem na obtenode baixos tempos de resposta.

Para alcanar o objetivo proposto, foi realizada em cada etapa do projeto uma avaliao dedesempenho para verificar quais mtricas utilizar e quais sistemas avaliar a fim de obter bonstempos de resposta contribuindo assim para a definio de qual sistema P2P o metaescalonadorproposto por Peixoto et al. (2010) pode utilizar e em que casos especficos.

1.3 Estrutura

Os prximos captulos sero estruturados da seguinte forma:

No Captulo 2 sero apresentados os conceitos relacionados computao em nuvem.Os conceitos apresentados permitem verificar quais as funcionalidades oferecidas, bemcomo os desafios proporcionados por esse modelo computacional;

4 1.3. ESTRUTURA

O Captulo 3 apresenta os conceitos referentes aos metaescalonadores. Nesse captuloser apresentado o metaescalonador ao qual esta proposta est vinculada. Alm de apre-sentar o metaescalonador, no captulo sero discutidas quais as diferenas deste metaes-calonador com os demais metaescalonadores encontrados na literatura;

O Captulo 4 apresenta os conceitos de comunicao em nuvem, com o foco em sistemasP2P. Esse captulo ir auxiliar na definio de qual sistema P2P utilizar nos experimentosa serem realizados;

No Captulo 5 sero discutidos os mtodos utilizados para o desenvolvimento das polti-cas de roteamento definidos para o metaescalonador. Ainda nesse captulo ser apresen-tado o ambiente de testes utilizado na elaborao deste projeto;

O Captulo 6 por sua vez, detalha os resultados de acordo com as polticas que foramsimuladas. Os resultados devem ajudar a identificar dentre as polticas utilizadas, emquais condies uma poltica pode ser melhor que as demais;

No Captulo 7 so apresentadas as concluses deste projeto bem como as dificuldadesencontradas e os trabalhos futuros.

Por fim so apresentadas as referncias bibliogrficas.

CAPTULO

2Computao em Nuvem

2.1 Consideraes Iniciais

A computao em nuvem assim intitulada por se tratar de um modelo computacional quepermite o acesso a recursos e informaes por meio da Internet e no localmente. A nuvemfacilita o uso de infraestrutura e plataforma computacional que pode ser dinamicamente confi-gurada e reconfigurada de acordo com as necessidades dos usurios (Zhang et al., 2010).

De acordo com o NIST (National Institute of Standards and Technology), a computao emnuvem um modelo que permite o acesso conveniente a conjuntos de recursos compartilhados,tais como: redes, servidores, armazenamento, aplicaes e servios, que podem ser disponibi-lizados ou liberados com certo esforo de gesto ou de interao com o provedor de servios(Mell e Grance, 2011). Nesse modelo, os usurios acessam os servios (software, plataforma einfraestrutura) utilizando, na maior parte das vezes, um navegador Web (Zhang et al., 2010).

A nuvem uma analogia a um conjunto de componentes que executam servios para osclientes sob demanda e, geralmente, o consumidor no tem ideia de onde estes servios esto,por isso dito que os servios esto nas nuvens (Rimal et al., 2009) conforme apresentado naFigura 2.1.

O funcionamento do sistema em nuvem se assemelha aos sistemas operacionais de rede,sistemas de tempo real e grades computacionais, onde os recursos computacionais so forneci-dos como um servio regular (Kim et al., 2009b) (Wu et al., 2010). A diferena entre a nuvemdos demais sistemas que a compe no o objetivo, mas sim as tecnologias existentes que seuniram para realizar a sua formao (Buyya et al., 2010).

5

6 2.2. VIRTUALIZAO

Figura 2.1: Ambiente de nuvem

Alm dos sistemas de grades computacionais e sistemas de tempo real, os servios de e-mailgratuito, servios de busca, portais de Internet, servios de hospedagem Web e alguns serviosde infraestrutura computacional so exemplos de servios oferecidos pela nuvem e que j eramutilizados antes da concepo do termo (Kim et al., 2009b).

Alm disso, esse sistema computacional incorpora virtualizao, desenvolvimento sob de-manda e entrega de servios Web na Internet. No existe uma inovao em arquitetura e in-fraestrutura, uma vez que esse sistema utiliza abordagens, conceitos e prticas que j foramestabelecidos h certo tempo (Carolan et al., 2009).

O que a difere dos outros sistemas que entregam servios a utilizao da virtualizao, queexplora ao mximo o uso do hardware disponvel (Carolan et al., 2009). A virtualizao podeser definida como a emulao de vrios computadores lgicos em um nico computador real.Essa caracterstica faz com que os usurios tenham a impresso de usarem um recurso fsico aoinvs de um recurso virtual (Chieu et al., 2009).

2.2 Virtualizao

De uma maneira geral, a computao em nuvem a migrao dos servidores de dentro deuma empresa para a nuvem. O usurio define os requisitos necessrios para que seus recur-sos sejam executados, como: processamento, rede de longa distncia e largura de banda. Eo provedor cria virtualmente esses servidores dentro da infraestrutura de nuvem (Zhang et al.,2010).

A facilidade de acesso aos servios sob demanda conduz a classificao da nuvem comoum paradigma para a computao de servios dinmicos que so geralmente apoiados por datacenters. Os data centers podem ser considerados como um conjunto de mquinas virtuais emrede (Buyya et al., 2010).

O conjunto de mquinas virtuais em rede s possvel devido virtualizao, que a di-ferena tecnolgica da computao em nuvem para os demais sistemas computacionais. A

CAPTULO 2. COMPUTAO EM NUVEM 7

virtualizao se refere principalmente melhor utilizao de recursos fsicos pelos usurios epor suas aplicaes. Alm disso, permite que os servidores, dispositivos de armazenamentoe hardware sejam considerados como um nico sistema, ao invs de sistemas separados, per-mitindo que esses recursos possam ser alocados dinamicamente pelos servidores (Chieu et al.,2009). A virtualizao adotada pela nuvem, pois, oferece vantagens no compartilhamento,gerenciamento e isolamento de recursos fsicos. Cada mquina virtual pode ter seu prprio sis-tema operacional, aplicaes e servios de armazenamento e rede (Carissimi, 2008) (Chieu etal., 2009).

A computao em nuvem, com a utilizao de virtualizao, permite que um nico servidorfsico execute vrios outros servidores lgicos que podem ter objetivos diferentes e sistemasdiferenciados uns dos outros (Chieu et al., 2009). Ao permitir essa execuo, o uso dos recursosna nuvem se torna mais eficiente, reduzindo os custos operacionais e de gesto da infraestrutura(Zhang et al., 2010).

2.3 Modelo Econmico

O pagamento pelos recursos da nuvem utilizados um diferencial quando comparado aoutras abordagens computacionais para a entrega de servios. Do ponto de vista empresarial, anatureza sob demanda desse sistema ajuda a incorporar aspectos de desempenho e capacidadeem nvel de servio (Carolan et al., 2009). Essa natureza econmica permite que as organizaescriem ambientes dinmicos onde recursos podem ser aumentados ou diminudos com base nacarga de trabalho e nos parmetros de desempenho do servio a ser executado. O pagamentopor recursos computacionais pode assumir a forma de contratos de locao de equipamentosgarantindo um nvel mnimo de servio por parte do provedor de nuvem (Carolan et al., 2009).

Com a migrao para a nuvem o usurio passa a pagar apenas pelos recursos efetivamenteutilizados, o que caracteriza o modelo pague o que utilizar, onde as garantias so ofereci-das pelo provedor de infraestrutura por meio de acordos em nvel de servio personalizado ouSLA (Service Level Agreement). O SLA serve como um nvel de contrato de servios, entre oprovedor e o cliente, que especifica o nvel em que o servio ser prestado (Gupta, 2010).

Assim, ao invs de negociar com uma organizao de tecnologia de informao (TI) os re-cursos de infraestrutura ou plataforma necessrios para a implantao de um servio, propostoo modelo de auto atendimento onde o cliente compra ciclos de computao e recebe uma in-terface Web ou uma interface de programao de aplicativos (API) para a criao de mquinasvirtuais (Carolan et al., 2009).

No necessrio um contrato de longo prazo entre o cliente e os prestadores de servios,os custos relacionados aos servios so cobrados por utilizao, e um aplicativo pode ser criadopara executar uma tarefa por poucos minutos ou poucas horas. Nesse sistema os aplicativos ouservios so considerados temporrios e o pagamento baseado no consumo de recursos como:

8 2.4. CARACTERSTICAS DA COMPUTAO EM NUVEM

CPU, volumes de dados movidos ou quantidade de dados armazenados (Furht, 2010) (Carolanet al., 2009).

A regra de negcios utilizada pela nuvem transfere os custos de manuteno da infraes-trutura que antes eram dos clientes para o provedor de servios (Carolan et al., 2009). Essainverso da responsabilidade tem consequncias significativas. No passado, os clientes deter-minavam como os diversos componentes de uma aplicao seriam definidos em um conjunto deservidores. Agora, um cliente pode usar a API de um provedor para criar no apenas a compo-sio inicial de uma aplicao, mas tambm como ela ir evoluir para acomodar as mudanasde carga de trabalho (Carolan et al., 2009).

2.4 Caractersticas da Computao em Nuvem

Os servios na nuvem podem ser considerados como uma arquitetura de camadas onde v-rios recursos esto disponveis em cada uma das camadas que formam a nuvem. Essas camadaspodem ser consideradas como um conjunto escalvel de recursos virtualizados que so capazesde hospedar aplicaes e fornecer servios aos usurios (Zhang et al., 2010). No mbito dacomputao em nuvem pode-se considerar que diferentes tipos de servios podem ser ofereci-dos, tais como: software, hardware, plataforma, dados, infraestrutura, dentre outros (Rimal etal., 2009). Os servios podem ser classificados em vrias camadas, que podem ser agrupadasem trs principais categorias (Ohlman et al., 2009) (Mell e Grance, 2011) como apresenta aFigura 2.2.

Computao em Nuvem

Google, Twitter, Facebook, Dropbox

Software como Servio (SaaS)

Google App Engine, Azure, Salesforce

Plataforma como Servio (PaaS)

Amazon EC2 S3, IBM Blue Cloud, HP

Infraestrutura como Servio (IaaS)

Figura 2.2: Camadas da Arquitetura em Nuvem. Adaptado de Rimal et al. (2009).

A primeira forma apresentada, SaaS, corresponde aos servios que esto hospedados nanuvem. Esses servios podem variar desde um servio de e-mail at editores de texto. O usurioutiliza o servio que pode ser pago ou gratuito (Peng et al., 2009) (Armbrust et al., 2009).

A segunda forma apresentada o PaaS, tambm conhecida como plataformas para a com-putao em nuvem. Nesse nvel o usurio interage na criao de aplicaes e na publicao das

CAPTULO 2. COMPUTAO EM NUVEM 9

mesmas, ficando assim a estrutura definida pelo fornecedor, como as tecnologias que sero uti-lizadas (.NET, Java, SGBDs), de forma fixa. Cabe ao usurio apenas escolher dentre as opesde plataforma a que melhor se enquadra nas suas necessidades (Armbrust et al., 2009) (Zhanget al., 2010).

Por ultimo apresentada a IaaS que a forma mais bsica de servio oferecido aos usurios(Zhang et al., 2010). Nessa forma os usurios contratam a infraestrutura (mquinas virtuais) earmazenamento e a partir deste ponto o usurio tem liberdade para criar sua plataforma bemcomo interagir com os servios (Rimal et al., 2009) (Zhang et al., 2010).

2.5 Tipos de Nuvem

As organizaes podem optar por implantar aplicativos em trs tipos de nuvens: pbli-cas, privadas ou hbridas, como apresenta a Figura 2.3, cada qual com caractersticas diferen-tes (Mell e Grance, 2011).

Figura 2.3: Formas de Desenvolvimento da Nuvem. Adaptado de (Furht, 2010)

As Nuvens Pblicas so gerenciadas por terceiros. Quem mantm as nuvens pblicas for-nece infraestrutura e servios aos usurios. Este modelo interessante para usurios que pre-cisam de flexibilidade e servios temporrios para executar suas tarefas, ou programas, e redu-zir custos com compra e manuteno de hardware (Furht, 2010). Os servios prestados pelasnuvens pblicas podem ser gratuitos como editores de texto, por exemplo, ou pagos como aAmazon EC2.

Nuvens Privadas so constitudas para prover recursos especficos para clientes particu-lares, isto , a infraestrutura pode ser alugada ou mesmo pertencer ao cliente (Furht, 2010)

10 2.6. PROVEDORES DE COMPUTAO EM NUVEM

(Zhang et al., 2010). Os clientes so, em sua maioria, empresas ou instituies pblicas ouprivadas e neste modelo a infraestrutura pode ser modificada de acordo com as necessidadesdesses clientes.

A Nuvem Hbrida um conjunto de funes ou utilizao das duas abordagens citadasanteriormente. Este modelo pode compartilhar temporariamente o uso de recursos das nuvenspblicas para garantir o desempenho de todos os servios, quando uma empresa privada temuma alta carga de trabalho (Furht, 2010) (Mell e Grance, 2011).

Os tipos de nuvens, como apresentado na Figura 2.3, no representam necessariamente alocalizao fsica da nuvem. As nuvens pblicas esto tipicamente na Internet e nuvens privadasesto normalmente localizadas nas dependncias de uma organizao privada que pode no serprestadora de servios em nuvem.

Uma nuvem privada pode ser hospedada no s nas dependncias da organizao, comopode tambm estar presente em provedores de infraestrutura como a Amazon (Zhang et al.,2010).

As organizaes podem fazer uma srie de consideraes a respeito do modelo ideal denuvem e que atenda aos seus interesses e pode ser adotado mais de um modelo de nuvem pararesolver problemas diferentes.

Um servio temporrio pode ser desenvolvido e utilizado de forma mais adequada em umanuvem pblica, pois evita a compra de equipamentos adicionais para resolver uma necessidadetemporria (Carolan et al., 2009). Da mesma forma, um servio permanente, ou que tem re-quisitos especficos sobre a qualidade do servio ou da localizao dos dados, pode ter umaimplementao mais adequada se for considerada uma nuvem privada ou hbrida.

Em qualquer tipo de nuvem, os usurios no precisam saber onde os dados esto sendoprocessados ou armazenados, a ideia que esses recursos esto na nuvem e podem ser acessadospor meio da Internet (Carolan et al., 2009).

2.6 Provedores de Computao em Nuvem

As principais aplicaes no domnio de nuvem incluem: Amazon Web Services, MicrosoftAzure e Google App Engine. Esses provedores de servios oferecem uma variedade de pacotesde servios de monitoramento, gerenciamento e provisionamento de recursos e servios (Furht,2010).

Os Webservices da Amazon Web Services (AWS)1: Elastic Load Balancer, Auto Scaling eCloudWatch, possuem funcionalidades que so necessrias para a alocao de servios e recur-sos do Amazon EC2.

O servio Elastic Load Balancer dispe automaticamente a carga dos aplicativos de entradaem vrias instncias do EC2 disponibilizados pela Amazon. J o servio de Auto Scaling pode

1http://aws.amazon.com/ec2/

CAPTULO 2. COMPUTAO EM NUVEM 11

ser usado para aplicar dinamicamente ou ampliar o nmero de instncias do Amazon EC2, paratratar alteraes na demanda dos servios (Ranjan et al., 2010).

Finalmente, o servio CloudWatch integrado com os outros Webservices para tomada dedecises estratgicas com base em informaes em tempo real dos recursos agregados e infor-maes sobre o desempenho dos servios (Ranjan et al., 2010).

O Windows Azure tem uma estrutura composta de nodos formados por servidores combalanceamento de carga. O Fabric Controller gerencia o nodo atravs de uma base de serviosdenominado agente controlador Azure, que monitora o estado do servidor. Se uma falha encontrada, o gerenciador pode administrar uma reinicializao do servidor ou a migrao dosservios do atual servidor para outros servidores que estejam funcionando normalmente (Zhanget al., 2010).

Ao contrrio de outras plataformas em nuvem, o Google App Engine oferece aos programa-dores uma plataforma escalvel. O acesso ao sistema operacional restrito pelo Google AppEngine. As estratgias de balanceamento de carga, servio de configurao e dimensionamentoso gerenciados automaticamente pelo sistema em segundo plano (Buyya et al., 2010).

A Tabela 2.1 apresenta uma comparao entre os principais fornecedores comerciais decomputao em nuvem.

Tabela 2.1: Comparao das Ofertas Comerciais

Amazon Google MicrosoftTipo de Servio IaaS PaaS IaaS PaaS - IaaS

Servio Ofertado Processamento e Processamento Processamento eArmazenamento Armazenamento

Interface de Acesso Interface Web e Interface Web e Portal AzureLinha de Comando Linha de Comando

Virtualizador Xen Continer de Aplicao Continer de ServioPlataforma Windows/Linux Linux Windows

Os fornecedores apresentados na Tabela 2.1 so os principais no fornecimento de serviosem nuvem, sendo os mesmo apresentados por (Vecchiola et al., 2009), (Buyya et al., 2010),(Ranjan et al., 2010), (Zhang et al., 2010).

Como apresentado na Tabela 2.1, enquanto a Amazon possui apenas solues IaaS, a Googlee a Microsoft fornecem infraestrutura e plataforma para desenvolvimento de aplicaes (Zhanget al., 2010).

O Google App Engine fornece um conjunto de APIs e um modelo de aplicao que permiteaos desenvolvedores utilizar servios adicionais fornecidos pelo Google, como o e-mail, Googlesites, editores de texto entre outros (Vecchiola et al., 2009).

Devido natureza dos servios ofertados pelo Google, apenas servios Web, o mesmo nofornece armazenamento. Diferentemente da Google, a Microsoft com a plataforma Azure ofe-

12 2.7. DESAFIOS DA COMPUTAO EM NUVEM

rece servios de armazenamento com o Azure Storage e SQL Data Service e a Amazon ofereceservios de armazenamento com o S3 (Zhang et al., 2010).

Alm de oferecer servios, os fornecedores precisam se preocupar com questes relaciona-das a segurana, tolerncia a falhas e bons tempos de resposta para os usurios, fazendo comque a nuvem seja adotada com confiana.

2.7 Desafios da Computao em Nuvem

A computao em nuvem oferece uma srie de benefcios em relao aos paradigmas com-putacionais anteriores a ela. No entanto, ainda h uma srie de desafios, que esto abertos apesquisa, tais como (Carolan et al., 2009) (Furht, 2010):

Desempenho Os servios executados na nuvem apresentam sobrecargas adicionais emrelao aos servios executados localmente. Devem ser consideradas as sobrecargas de-vido ao gerenciamento da nuvem e das mquinas virtuais. Alm disso, os usurios queesto a distncias considerveis dos provedores podem ter alta latncia e atrasos;

Segurana As aplicaes devem fornecer acesso apenas a usurios autorizados e au-tenticados e os usurios precisam ser capazes de confiar que seus dados no foram ma-nipulados por outras pessoas. A segurana no ambiente de nuvem deve ser estabelecidapor meio de autenticao forte, autorizao e procedimentos nas contas dos usurios,estabelecendo a segurana dos dados no inicio das transaes, trafego das informaes efinalizao das sesses. A segurana deve ser integrada em todos os aspectos da aplicaoe sua implantao na arquitetura das nuvens deve ocorrer em todos os processos;

Escalabilidade Os servios projetados para a computao em nuvem precisam ser es-calveis de acordo com as cargas de trabalho que chegam a esses servios. Para alcanarisso, os servios e os dados devem ser flexveis para maximizar a escalabilidade;

Disponibilidade Como o modelo de computao em nuvem segue o modelo de pagueo que utilizar, o usurio espera que os servios contratados estejam em continuo funcio-nando;

Confiabilidade Os componentes de um sistema que oferece servio na nuvem devem teras falhas minimizadas e a sua manuteno deve ser possvel sem interrupo dos serviosprestados. Um ponto crucial em termos de confiabilidade est relacionado com a perdade dados. A ideia que as aplicaes operem os dados, e esses permaneam intactos,mesmo se apresentar falha em um ou mais servidores ou mquinas virtuais no qual osdados so armazenados ou processados;

CAPTULO 2. COMPUTAO EM NUVEM 13

Flexibilidade e agilidade A computao em nuvem pode melhorar o processo de cri-ao de servios, criando servidores de plataforma com servios mais flexveis, ou seja,suportando um grande nmero de frameworks de desenvolvimento e suportando vriaslinguagens de programao;

Manuteno Depois que um aplicativo implantado, ele precisa ser mantido. Isso querdizer que quando um servio tem que ser reparado o tempo de inatividade tem que sermnimo. Os componentes de um aplicativo ou de infraestrutura devem ser atualizados oumesmo substitudos sem interromper o fornecimento do servio;

Interoperabilidade As plataformas normalmente oferecem APIs de acordo com suainfraestrutura. necessrio que existam linguagens padronizadas entre os diversos for-necedores de servio tanto em relao infraestrutura como em relao a plataformas eservios.

Avanos na arquitetura de aplicao ajudam a promover a computao em nuvem. Comopode ser observado nesta seo, os desafios e as preocupaes com a utilizao desse sistemacomputacional so similares quelas observadas na utilizao de novos aplicativos para aplica-es crticas. A maior diferena entre os dois casos a confiana dos clientes em deixar seusdados e os recursos necessrios para executar seus servios sob a responsabilidade de terceiros.

2.8 Plataforma de Desenvolvimento

No desenvolvimento de servios necessrio, alm do desenvolvimento e avaliao dosmtodos utilizados, avaliar a arquitetura que ser utilizada e suas especificaes. Como apre-sentado na Seo 2.6, os provedores de servio possuem caractersticas referentes aos serviosofertados e consequentemente esses servios devem ser distribudos entre os diversos data cen-ters pertencente a esses provedores.

Como a nuvem apresenta desafios no desenvolvimento de novas polticas, sejam elas paraescalonamento de mquinas virtuais, escalonamento de hosts, descoberta de servios entre ou-tras, torna-se complexo desenvolver tais polticas e executar testes controlveis, que possibili-tem a repetio dos mesmos em um ambiente homogneo e inalterado (Calheiros et al., 2010).

Alm disso, o presente projeto de mestrado aborda caractersticas que so relacionadas infraestrutura da nuvem (descoberta de servios) tornando assim mais custoso o processo dedesenvolvimento de polticas e testes, uma vez que a manipulao de uma infraestrutura pri-vada, por terceiros, praticamente impossvel devido a diferentes questes, dentre elas a maissignificativa a segurana.

Assim, considerando as limitaes impostas pela aferio nos sistemas de nuvem, para odesenvolvimento de polticas para a nuvem, a metodologia mais adequada a utilizao demodelagem e simulao.

14 2.8. PLATAFORMA DE DESENVOLVIMENTO

Alguns simuladores para sistemas distribudos e para grades computacionais esto dispon-veis (Bell et al., 2003) (Casanova et al., 2008) (Ostermann et al., 2011). No entanto, o que maisse adequa para simulao de computao em nuvem e que o mais amplamente utilizado oCloudSim (Calheiros et al., 2010).

Trabalhos como os apresentados por (Kim et al., 2009a), (Beloglazov e Buyya, 2010), (Jeya-rani et al., 2010), (Sindhu e Mukherjee, 2011) e (Shi et al., 2011) so exemplos da flexibilidadee possibilidades oferecidas pelo CloudSim.

2.8.1 CloudSim

O CloudSim adota uma arquitetura de multicamadas modulares para realizar a gerncia dosseus componentes de forma separada (Calheiros et al., 2010). Estes componentes so apresen-tados na Figura 2.4.

Cdigo do Usurio

Especificaes da

Simulao

Escalonamento

Requisitos Configurao do Servio...

Broker ... Metaescalonador

CloudSim

Estrutura da Interface do Usurio

Cloudlet Mquina Virtual

Servios VM Execuo da Cloudlet Manuteno da Mquina Virtual

Servios da NuvemConfigurao de VM Alocao de CPU Alocao de Memria

Alocao de Armazenamento Alocao de Banda

Recursos da Nuvem

Manipulao de Eventos Sensores Coordenador da Nuvem

Data Centers

Rede Topologia da Rede Clculo do Delay da Rede

Ncleo de Simulao CloudSim

Cenrio

Figura 2.4: Arquitetura do Simulador. Adaptado de (Calheiros et al., 2010)

Como apresentado na Figura 2.4, o CloudSim possui vrios mdulos que so, por sua vez,agrupados em trs categorias:

Cdigo do Usurio onde so definidos os cenrios da simulao como: configuraodos data centers, quantidade de hosts, valor monetrio dos recursos, nmero de clientese a quantidade de brokers ou metaescalonadores;

CAPTULO 2. COMPUTAO EM NUVEM 15

CloudSim mdulo para definio das polticas que sero desenvolvidas na nuvem.Como separado em mdulos, o desenvolvimento de novas polticas pode ser feita deforma independente;

Ncleo de Simulao nessa categoria so encontrados os gerenciadores de eventos e asfilas utilizadas pelo simulador.

Dentre os mdulos que compe a arquitetura do CloudSim est o mdulo de rede (categoriaCloudSim). A presena desse mdulo demonstra que o simulador no se preocupa apenas comos servios (denominados cloudlets), mquinas virtuais e data centers, mas tambm em comoa comunicao realizada na nuvem (Calheiros et al., 2010).

De acordo com Calheiros et al. (2010) o simulador no conta com entidades reais paraa simulao de entidades de rede, como roteadores ou switches. Em vez disso, utilizadaa latncia que uma mensagem possui entre sua entidade de origem (cliente) para a entidadedestino (data center). A latncia entre essas entidades armazenada em uma matriz do tipoNxN e a informao de delay utilizada sempre que uma mensagem enviada entre a origeme o destino.

O CloudSim necessita de uma topologia de rede para a descrio das caractersticas da redecomo: a quantidade de nodos disponveis e os pesos das arestas de ligao entre um nodo eoutro. Essas informaes so necessrias para que o simulador possa utilizar essas informa-es para gerar a sobrecarga da rede (Calheiros et al., 2010). A topologia de rede, que auxilianas atividades relacionadas rede, no so geradas pelo CloudSim e sim por um gerador detopologias de rede denominado BRITE (Medina et al., 2001).

O BRITE utilizado para compor arquivos de configurao que possuem as caractersticasda rede como quantidade de nodos presente na rede e o peso das arestas de ligao entre osnodos (Calheiros et al., 2010).

2.8.2 Brite

O BRITE um gerador de topologias que no se restringe a apenas uma forma de gerartopologias (Medina et al., 2001). Por se tratar de um gerador de topologias genrico, ele fornecevrias formas de construir topologias e de modelos de distribuio de nodos (Medina et al.,2001). A Figura 2.5 apresenta uma viso geral do BRITE.

O BRITE possui o modelo de distribuio de nodos (1) e as derivaes do modelo utilizado.Os modelos que podem ser utilizados pelo BRITE so: Waxman (Waxman, 1988) e Barabasi-Albert (Albert e Barabsi, 2000).

Segundo Naldi (2005), o modelo Waxman um modelo de gerao de grafos aleatrios paramodelar topologias de rede com o propsito de avaliar algoritmos de roteamento. Esse modeloutiliza propriedades espaciais para gerar a conectividade do grafo.

16 2.8. PLATAFORMA DE DESENVOLVIMENTO

SSFBrite

Formato

NSModelo 1 Nodos

Grafo

Arestas

Modelo

Topologia

Modelo 2 Modelo N

Membros

(3)(2)(1)

Deriva

...

Figura 2.5: Mdulos que Compe o BRITE. Adaptado de (Medina et al., 2001)

O grafo contm um nmero N de nodos que so distribudos uniformemente sobre um planoretangular. Cada nodo possui coordenadas cartesianas inteiras que so utilizadas para gerara conectividade do grafo, ou seja, a conectividade dos nodos est relacionada com a relaoespacial entre eles (suas distncias no plano) (Waxman, 1988) (Naldi, 2005).

Albert e Barabsi (2000) prope um mecanismo gerador de grafos que usa a lei de distri-buies de potncia, tambm chamada de apego preferencial. Nesse modelo a rede cresce deforma incremental e a interconexo entre os nodos feita de acordo com a proximidade dosnodos no plano cartesiano.

Esse modelo sugere duas formas possveis para a gerao das topologias de rede: cresci-mento incremental e conectividade preferencial. Crescimento incremental refere-se a adiocontnua de novos nodos, e, portanto, o aumento gradual no tamanho da rede. Conectividadepreferencial refere-se tendncia de um nodo ligar-se a outros nodos que esto prximos a ele(Albert e Barabsi, 2000).

O grafo gerado com as informaes sobre o tamanho do plano e a quantidade de nodosque iro compor a simulao (2). As ligaes entre esses nodos so feitas utilizando um dosalgoritmos citados anteriormente.

Assim, de posse da topologia gerada pelo BRITE, gerado um arquivo de topologia (3) quepode ser salvo como BRITE, SSF, NS e JSim (Medina et al., 2001).

Com a utilizao das ferramentas descritas nessa seo fornecido, por meio de simulao,um ambiente onde a nuvem pode ser avaliada considerando vrias caratersticas. Dentre ascaractersticas que podem ser analisadas est a rede, possibilitando assim o uso do CloudSimpara o desenvolvimento de polticas de roteamento que podem ser utilizadas por provedores decomputao em nuvem.

CAPTULO 2. COMPUTAO EM NUVEM 17

2.9 Consideraes Finais

A computao em nuvem dependente da qualidade de conexo disponvel para o utilizadordos diversos servios (Pokharel e Park, 2009), uma vez que todos os servios so acessados pormeio da Internet. importante investigar maneiras de prover QoS, com relao comunicao,para as aplicaes e servios desse ambiente.

Essa forma de computao agrega oportunidades para que servios sejam migrados de ser-vidores locais para servidores remotos. Contudo, necessrio avaliar o funcionamento dascamadas que a compe, uma vez que a tendncia que este modelo computacional cresa eatinja grandes propores. Servios e polticas de computao em nuvem se utilizados sempassar por avaliaes de desempenho, para verificar a viabilidade de utilizao em determina-das atividades, podem no prover um QoS satisfatrio aos clientes.

Por parte dos fornecedores, necessrio monitorar a nuvem para escalonar os servios dosusurios. Assim, surge a necessidade de criar interfaces para que os usurios possam definir asconfiguraes mnimas para que suas aplicaes possam ser executadas com qualidade.

Essas interfaces podem ser brokers, escalonadores ou metaescalonadores que so desenvol-vidos para monitorar os recursos disponveis. Entender como os escalonadores dos fornecedo-res funcionam pode trazer benefcios na identificao de possveis gargalos e assim melhorar aqualidade na forma como os servios so ofertados e entregues pela nuvem.

CAPTULO

3Metaescalonadores

3.1 Consideraes Iniciais

Como a nuvem um ambiente de computao distribudo, necessrio que haja mecanis-mos para o gerenciamento dos recursos desse ambiente (Buyya et al., 2010). Como esse sistema formado por um conjunto de data centers (Zhang et al., 2010) deve-se ter dois tipos de esca-lonadores: um para monitorar os recursos da nuvem e outro para monitorar as diversas nuvens(Xhafa e Abraham, 2010).

O primeiro tipo de escalonador o escalonador local (Christodoulopoulos et al., 2009).Esse escalonador controla os recursos dos data centers em nvel de recursos disponveis, comoarmazenamento e processamento (Christodoulopoulos et al., 2009).

Quando h vrias nuvens a serem monitoradas, o escalonamento pode ser feito utilizandoum broker ou um metaescalonador (Yamini et al., 2011). Um metaescalonador esconde a com-plexidade do mecanismo de escalonamento utilizado pela nuvem provendo assim uma formatransparente de alocao de recursos para a execuo dos servios dos clientes (Liu et al., 2008)(Heidt et al., 2008) (Mann, 2005).

Os metaescalonadores so utilizados para distribuir os servios em servidores, baseadosnos requisitos do cliente (Buyya et al., 2010). Diferentemente dos escalonadores locais, osmetaescalonadores no possuem controle direto sobre os recursos da nuvem, ou seja, ele repassaao escalonador local as solicitaes realizadas pelos clientes e os escalonadores locais repassamaos metaescalonadores informaes de disponibilidade (Yamini et al., 2011).

19

20 3.2. ESCALONADORES LOCAIS E METAESCALONADORES

3.2 Escalonadores Locais e Metaescalonadores

Metaescalonadores e escalonadores locais so duas solues, que normalmente coexistem,para o escalonamento em sistemas distribudos como, por exemplo, em grades computacionaise nuvens (Xhafa e Abraham, 2010).

Weissman e Grimshaw (1996) prope uma forma de escalonamento para sistemas distribu-dos baseado em gerenciamento de recursos locais (LRMS - Local Resource Management Sys-tem). Cada participante desse ambiente precisa iniciar um gerenciador local e um gerenciadorglobal de recursos. O gerenciador global conta com duas interfaces: a interface do gerenciadorde escalonamento para os escalonadores locais e, o escalonador da grade para os gerenciadoresde escalonamento remoto. O compartilhamento de informaes pode ser acessado a qualquermomento e os arquivos so estticos.

Seguindo a linha de utilizao de metaescalonadores, Schwiegelshohn e Yahyapour (1999)apresentam um metaescalonador denominado NWIRE (Net-Wide-Resources). O NWIRE con-siste em um meta-gerenciador que responsvel por controlar o conjunto de domnios ou meta-domnios que possu acesso ao gerenciador de recursos (LRMS). O NWIRE utiliza vrias ca-ractersticas de escalonamento incluindo a existncia de escalonadores convencionais e reservade recursos.

Subramani et al. (2002) apresenta um modelo de escalonamento de computao distribudaque se adapta s mudanas do uso dos recursos. O objetivo central foi propor um metaescalo-nador que considera a distribuio de tarefas em vrios servidores ao invs de encaminh-losao servidor menos sobrecarregado.

O metaescalonador proposto utiliza a tcnica de backfilling, que consiste em balancear autilizao e manuteno das tarefas com base em fila (Subramani et al., 2002).

Outra infraestrutura de escalonamento baseada nas mudanas do uso de recursos apresen-tada pelo OurGrid, que utiliza como critrio de escalonamento a reputao e a disponibilidadedos recursos (Andrade et al., 2003).

Com a difuso dos metaescalonadores as tcnicas utilizadas, at ento para grades com-putacionais, foram sendo aprimoradas como apresentado por Iosup et al. (2007). O meta-escalonador proposto utiliza uma arquitetura hierrquica no qual os recursos de mesmo nvelpodem cooperar entre si. Essa abordagem descentralizada permite a cooperao entre vriasorganizaes diferentes sem a necessidade de um ponto central de controle.

Leal et al. (2009) apresenta o GridWay e discute o seu modelo descentralizado de escalona-mento para mltiplas organizaes que trabalham de forma cooperativa. Esse esquema propeum metaescalonador para cada infraestrutura da organizao. O mtodo foi uma alternativa paraas limitaes apresentadas por metaescalonadores com modelo centralizado.

Uma abordagem de escalonamento dinmico descentralizado proposta por Huang et al.(2011). Essa abordagem denominada CASA (Community Aware Scheduling Algorithm) e

CAPTULO 3. METAESCALONADORES 21

funciona como um escalonamento de duas fases. Na primeira fase, uma tarefa submetida aonodo mais adequado entre os participantes do ambiente. Na segunda fase, onde ocorre o esca-lonamento dinmico, o objetivo melhorar as decises do escalonamento de forma interativa.

Como apresentado nos trabalhos descritos anteriormente, h basicamente trs modelos detroca de informao entre os metaescalonadores e os escalonadores locais. A Figura 3.1 apre-senta o modelo centralizado de comunicao entre os metaescalonadores e os escalonadoreslocais.

Metaescalonador

Requisio

Distribuidor Local Distribuidor LocalDistribuidor Local

Fluxo da Requisio

Fluxo da Informao

Figura 3.1: Modelo Centralizado de Troca de Informaes

No modelo apresentado na Figura 3.1, h um metaescalonador principal que mantm infor-maes de carga de trabalho sobre todas as organizaes participantes (Weissman e Grimshaw,1996). Os servios so enviados para o metaescalonador que decide qual distribuidor local irreceber os servios. Este modelo apresenta algumas desvantagens causadas pela centralizao,tais como: difcil escalabilidade e problemas com tolerncia a falhas (Subramani et al., 2002).

A Figura 3.2 apresenta o modelo distribudo (Leal et al., 2009) (Huang et al., 2011).

Metaescalonador

Requisio

Distribuidor Local

Fluxo da Requisio

Fluxo da Informao

Metaescalonador

Requisio

Distribuidor Local

Metaescalonador

Requisio

Distribuidor Local

Figura 3.2: Modelo Descentralizado de Troca de Informaes

No modelo apresentado na Figura 3.2, cada ambiente possui seu prprio metaescalonadorque periodicamente consulta os outros metaescalonadores para obter informaes da carga ins-tantnea de recursos (Subramani et al., 2002). Os servios so enviados para o metaescalonador

22 3.3. MACC

local que decide, dentre os escalonadores locais, qual deles ir executar os servios ou se hnecessidade de migrar os servios para outro ambiente.

E por fim h o modelo hierrquico, Figura 3.3, onde o fluxo de trabalho compartilhado en-tre os metaescalonadores (Subramani et al., 2002). Os recursos do metaescalonador de mesmonvel cooperam entre si (Iosup et al., 2007).

Metaescalonador

Requisio

Escalonador Local /Distribuidor

Fluxo da Requisio

Fluxo da Informao

Escalonador Local /Distribuidor

Escalonador Local /Distribuidor

Figura 3.3: Modelo de Troca de Mensagens Hierrquicas

Neste modelo os servios so enviados para o metaescalonador mais prximo ao cliente eno h fila de servios. O metaescalonador envia o servio para o ambiente que estiver dispo-nvel e que satisfaa os requisitos de QoS dos clientes. Cada ambiente pode usar diretivas deagendamento diferentes devido ao fato de possurem um metaescalonador local e cada meta-escalonador local interagir com os escalonadores locais (Subramani et al., 2002) (Iosup et al.,2007).

Os modelos de troca de informao seguiram a evoluo da computao em grade e hoje hmodelos bem difundidos que derivam dos modelos apresentados anteriormente (Chard, 2011).A evoluo dos metaescalonadores por sua vez, permite que esta abordagem seja utilizada almdos domnios de computao em grade (Chard, 2011). Assim, proposto por Peixoto et al.(2010) um metaescalonador denominado MACC (Metascheduler Architecture to provide QoSin Cloud Computing) que considera a evoluo dos metaescalonadores do ambiente de gradescomputacionais para o ambiente de nuvem.

3.3 MACC

Como foi discutido na seo 3.2, um metaescalonador uma abordagem computacional quepermite a alocao de servios, com o objetivo de distribuir a carga entre os vrios provedoresde servios de um ambiente ou de uma federao de ambientes (Peixoto et al., 2009).

O conceito de federaes consiste na unio de diversos provedores de computao em nu-vem que possuem propsitos de negcios semelhantes, possibilitando assim o acesso a servios

CAPTULO 3. METAESCALONADORES 23

de nuvem de forma escalar, mesmo sobre diferentes provedores dessa federao (Buyya et al.,2010).

Assim, o MACC um metaescalonador que torna possvel prover QoS na computao emnuvem. A sua principal funo realizar a manuteno dos critrios de QoS, fazendo com queos servios sejam requisitados de forma transparente aos clientes.

O cliente encaminha as solicitaes ao MACC, que segue o modelo hierrquico de comuni-cao entre escalonadores locais e metaescalonadores. O MACC realiza um escalonamento emduas camadas. A primeira camada realiza uma pesquisa sobre qual federao pode oferecer osrequisitos de qualidade de servios ao cliente, encaminhando assim os servios ao escalonadorlocal. A segunda camada realiza o escalonamento de acordo com as informaes de recursosda federao, que ir processar as solicitaes do cliente.

Para realizar a atividade descrita anteriormente, o MACC utiliza vrios mdulos como apresentado na Figura 3.4. Cada mdulo orientado QoS, sendo assim, o MACC possuium mdulo que se preocupa com os servios e requisies dos clientes. Esse tratamento importante, uma vez que necessrio analisar quais os atributos de QoS devero ser abordadosno atendimento dos servios.

O mdulo de controle de admisso dependente do mdulo de controle de valores que responsvel por verificar os contratos (SLAs) estabelecidos com o cliente. Nesse mdulo encontrado o modelo econmico utilizado pelo MACC.

CPU (Processamento)

Aplicaes Armazenamento

Hypevisor (Xen, VMWare, etc.)

Outros recursos

MDSN

Index Services

Trigger Services Workload Engine

Polticas de Escalonamento

LRAM

Controle de Admisso Controle de Valores

Servios, Requisies

Ncleo do Metaescalonador

Cache UDDI

Figura 3.4: Arquitetura do MACC

O ncleo do MACC apresenta vrios outros mdulos que so responsveis diretos na obten-o da QoS que ser oferecida aos clientes. Esses mdulos so descritos como (Peixoto et al.,2010):

Cache UDDI - Armazena informaes sobre servios locais e sobre os servios remotosfacilitando a busca por esses servios;

24 3.4. QUALIDADE DE SERVIO

LRAM - Gerenciador de Alocao de Recursos Local. Esse mdulo utiliza os mduloshypervisor e de recursos apresentados na Figura 3.4 para o gerenciamento dos recursoslocais das federaes;

Polticas de Escalonamento - Esse mdulo responsvel pelas polticas de roteamentoutilizadas na primeira fase de escalonamento e pelas polticas de alocao de mquinasvirtuais utilizadas na segunda fase de escalonamento;

Workload Engine - Esse mdulo faz a estimativa do tempo necessrio que um servionecessita para a utilizao dos recursos da federao;

Monitoring and Discovery System Manager (MDSN) - Esse mdulo utilizado para alocalizao dos registros de servios disponveis. Para essa localizao esse mdulo contacom:

Trigger Service - Esse submdulo responsvel por notificar as mudanas dos re-cursos como expanso ou diminuio de recursos.

Index Service - Esse submdulo desempenha o endereamento de cada recurso re-quisitando dados de desempenho.

Os mdulos apresentados tm como objetivo trabalharem em conjunto formando assim umainfraestrutura em que cada mdulo se preocupa com a obteno de QoS relacionado atividadeparticular do mdulo e geral do MACC.

3.4 Qualidade de Servio

Segundo Chard (2011) uma das formas de manter os nveis de QoS estabelecer acordos,como uma SLA entre clientes e provedores. Sendo assim, An et al. (2010) prope o uso demodelos econmicos para a alocao de recursos com foco na negociao de mercado dinmica.

Comparado ao modelo apresentado por An et al. (2010), o MACC tambm se preocupa como estabelecimento de um preo inicial, porm os preos so regidos por uma SLA, que contacom uma definio de obrigaes por parte do provedor de servios para os clientes (Peixoto etal., 2010).

Alm das regras de mercado, h trabalhos (Gmach et al., 2009) (Zhu et al., 2008) que reali-zam a alocao dinmica de CPU para cumprir os objetivos de QoS. Alm disso, oferecida adiferenciao de servio por meio da alocao baseada em prioridades.

O que diferencia os trabalhos citados anteriormente do MACC que o MACC possui umfornecimento de QoS fim-a-fim. Existe uma preocupao em garantir QoS tanto em nvel derede como em nvel de aplicao, diferenciando assim o MACC de outros metaescalonadores(Peixoto et al., 2010).

CAPTULO 3. METAESCALONADORES 25

A Tabela 3.1 apresenta uma comparao entre metaescalonadores de grades computacionaisapresentados em Peixoto et al. (2010) e interfaces de acesso utilizados pela nuvem apresentadosem Zhang et al. (2010), Buyya et al. (2010) e Ranjan et al. (2010) e que vo ao encontro dasfunes do MACC.

Tabela 3.1: Comparao entre MetaescalonadoresMetaescalonador Middleware Balanceamento de Carga Tipo de Servios Algoritmo de Escalonamento Auto escalvel

CSF Globus Reserva de Recursos Independente Round Robin NoGridway Globus Round Robin Independente Round Robin NoAmazon EC2 Definido por arquivos Infraestrutura DNS Sim

de configuraoMicrosoft Azure Automtico Plataforma e CDN Sim

InfraestruturaGoogle App Engine Automtico Plataforma e Manual Sim

InfraestruturaRackspace CLB Automtico Infraestrutura Round Robin Sim

GoGrid Cloud Definido por arquivos Infraestrutura Round Robin e ManualHosting de configurao Last connect algorithmMACC Baseado em QoS Independente P2P Sim

A Tabela 3.1 apresenta caractersticas referentes aos metaescalonadores e interfaces de con-figurao de servios em nuvem que funcionam como escalonadores. Os metaescalonadoresde grades apresentam vantagens como: independncia de plataforma, porm no apresentamescalabilidade (Foster e Kesselman, 1997) (Foster e Kesselman, 1999).

As polticas de escalabilidade devem ser programadas pelo cliente de acordo com a aplica-o (Foster e Kesselman, 1999). Diferente dos metaescalonadores para grade, os fornecedoresde servios nas nuvens possuem em sua maioria um nvel mais alto de escalabilidade e balan-ceamento de carga automtico (Zhang et al., 2010).

O MACC quando comparado a outros metaescalonadores apresenta vantagens relacionadasao balanceamento de carga, que avaliada de acordo com a qualidade de servio que seroferecida aos clientes (Peixoto et al., 2010). Essa caracterstica visa auxiliar o balanceamentode carga uma vez que os escalonadores que utilizam mtodos automticos podem no consideraros atributos corretos para esse controle.

O MACC apresenta vantagem sobre o Gogrid (Ranjan et al., 2010) em relao ao balan-ceamento de carga e auto escalabilidade, uma vez que, no Gogrid essas polticas precisam serdesenvolvidas de acordo com a aplicao. O MACC, por sua vez, possui suas polticas voltadas qualidade de servio (Peixoto et al., 2010).

Outro diferencial entre o MACC e os escalonadores especficos para nuvem relacionadoao modelo de comunicao. A abordagem mais utilizada o Round Robin devido ao balance-amento de carga feito no nvel de roteamento (Ranjan et al., 2010). Na Amazon a localizaode onde os servios sero instanciados de responsabilidade do cliente e o escalonamento dasinstncias feito de acordo com as especificaes das aplicaes. O trfego das aplicaes automaticamente distribudo pelo EC2 utilizando Domain Name Service (DNS) fazendo umbalanceamento de carga no nvel de roteamento interno (Amazon, 2012).

26 3.5. CONSIDERAES FINAIS

O Windows Azure utiliza a tcnica de Content Delivery Network (CDN) que consiste emcriar cpias dos dados em servidores mais prximos dos clientes. Essa tcnica consiste em ca-ches de objetos estticos para diminuir o tempo de carregamento das aplicaes para os clientes(Microsoft, 2012).

Enquanto os escalonadores e metaescalonadores possuem, em sua maioria, apenas um algo-ritmo ou tcnica para o roteamento das aplicaes, o MACC possui um modelo de comunicaoque pode utilizar algoritmos convencionais com o Round Robin ou mesmo sistemas P2P (Pei-xoto et al., 2010). Essa caracterstica do MACC permite que o modelo de comunicao possaevoluir de acordo com a evoluo da computao em nuvem.

3.5 Consideraes Finais

Independentemente do contexto envolvido, os tipos de gerenciamento de QoS devem in-cluir requisitos, tais como: mapeamento e negociao de QoS, estabelecimento de uma SLA emonitoramento de QoS (Guo et al., 2007) (Foster et al., 1999). O mapeamento dos melhoresatributos de QoS no uma tarefa simples e depende dos objetivos do cliente, bem como dacapacidade do provedor de servio para prover as caractersticas necessrias a esses clientes.

Os metaescalonadores auxiliam nessa tarefa de mapeamento utilizando informaes de ou-tros metaescalonadores e de escalonadores locais, como foi apresentado nesse captulo. Ummetaescalonador formado por vrias partes que devem trabalhar em conjunto para atingir umobjetivo comum (Peixoto et al., 2010).

Como apresentado at aqui, o MACC composto por vrios mdulos, e dentre esses m-dulos ser dada uma ateno maior ao mdulo de escalonamento. Esse mdulo deve conteralgoritmos responsveis pelo roteamento das solicitaes dos clientes. Para que essa atividadeseja executada de forma a obter um nvel aceitvel de QoS necessrio que as polticas deroteamento sejam avaliadas seguindo metodologias j consolidadas para que o desempenho doMACC no seja afetado.

Essa avaliao necessria devido ao modelo de fornecimento de QoS do MACC que possuium modelo fim-a-fim. Dessa forma, a atividade de comunicao tambm deve ser abordada.

CAPTULO

4Comunicao nas Nuvens

4.1 Consideraes Iniciais

A reduo dos custos da Internet e a facilidade de acesso a esse meio, que pode ser aces-sado por dispositivos variando desde computadores pessoais at telefones celulares, tendem aimpulsionar a computao em nuvem (Furht, 2010), uma vez que essa abordagem enfatiza ahabilidade de oferecer servios pela Internet com foco na prestao de servios sob demanda(Buyya et al., 2010).

Nesse caso, os provedores de computao em nuvem esto espalhados em diferentes loca-lizaes geogrficas, pela Internet, com o objetivo de oferecer melhores servios aos clientes(Ranjan et al., 2010). Essa distribuio geogrfica visa diminuir a distncia entre os clientes eos provedores e com isso fornecer servios com segurana, confiabilidade e tolerncia a falhas(Peixoto et al., 2010).

No suficiente ocorrer apenas comunicao entre os provedores que esto dispersos geo-graficamente. Essa comunicao deve vir acompanhada de caractersticas que proporcionemaspectos de QoS como baixos tempos de resposta e tolerncia a falhas tanto na descobertaquanto na entrega de recursos e servios (Peixoto et al., 2010).

4.2 Descoberta de Recursos

A descoberta de servios desempenha um papel fundamental na obteno de QoS dentroda computao em nuvem. Chard (2011) apresenta o conceito de metaescalonadores que, utili-

27

28 4.3. P2P

zando middlewares para descoberta de recursos e servios, podem fornecer qualidade de servi-os em atividades tanto de grades computacionais quanto de ambientes de nuvem.

importante considerar o modelo que ser seguido para a descoberta de servios. Osmodelos utilizados para essa descoberta seguem abordagens centralizadas ou descentralizadas(Chard, 2011).

O foco deste trabalho de mestrado no estudo de modelos descentralizados, uma vez queos modelos centralizados apresentam, em sua maioria, problemas como ponto nico de falha enem sempre esse modelo proporciona tolerncia a falhas e escalabilidade (Ranjan et al., 2010).

J os sistemas descentralizados podem ser usados para minimizar algumas das limitaesapresentadas pelo modelo centralizado. A descoberta de recursos na forma distribuda ge-ralmente baseada em abordagens hierrquicas ou P2P (ponto a ponto) (Peixoto et al., 2010).O Ganglia (Massie et al., 2004) uma arquitetura de descoberta de recursos hierrquica. Aprpria entidade responsvel nomeia as informaes sobre os recursos e gerencia onde essasinformaes devem ser armazenadas.

A descoberta de servios pode ser baseada em sistemas P2P, onde as informaes encontram-se distribudas entre os nodos da rede (Ranjan et al., 2006). Em estruturas P2P puras, pode-seafirmar que, nenhum nodo tem funo mais importante do que outro. Pela prpria definio,essa arquitetura tolerante a falhas, reorganizvel e escalvel. Por causa dessas caractersticas,h vrios sistemas P2P, que podem ser utilizadas para auxiliar na descoberta de servios emsistemas distribudos, propostas na literatura (Ranjan et al., 2008).

4.3 P2P

Os sistemas ponto a ponto (P2P) so aplicaes que surgiram como uma alternativa aostradicionais sistemas cliente-servidor (Kurose et al., 2010). Diferente de aplicaes Web, ser-vidores de e-mail e at mesmo o Domain Name Service (DNS), que necessitam de servidorescentralizados, os sistemas P2P possuem uma dependncia mnima (nem sempre necessrio)de servidores centralizados para a troca de informao (Kurose et al., 2010).

Os sistemas P2P representam uma forma de construir sistemas e aplicativos distribudos,onde os dados e recursos computacionais so derivados da colaborao de muitos pontos naInternet de maneira uniforme. Os pontos que compe uma rede P2P podem atuar tanto comoservidores quanto como clientes sem uma coordenao centralizada (Lua et al., 2005).

De acordo com Kurose et al. (2010) os sistemas P2P podem servir para a distribuio dearquivos, construo de um banco de dados distribudo tambm conhecido como DistributedHash Table (DHT) e telefonia pela Internet (Voip).

Neste trabalho de mestrado ser utilizado o conceito de DHT por considerar a descoberta derecursos e no o compartilhamento de arquivos ou aplicaes.

CAPTULO 4. COMUNICAO NAS NUVENS 29

4.3.1 Caractersticas dos Sistemas P2P

Segundo Ranjan et al. (2006), as redes P2P apresentam caractersticas relacionadas orga-nizao da rede, organizao dos dados e a forma de roteamento. A taxonomia da Figura 4.1apresenta as formas de diviso feitas pelos sistemas P2P.

P2P Taxonomia

Organizao da Rede Organizao dos Dados Consulta/Roteamento

Estruturada No Estruturada

GnutellaKazaaCAN Pastry

Estruturada No Estruturada

AleatrioDefine a Posio do dado na rede

Estruturada No Estruturada

Busca em Largura

Hierrquia da Rede

Busca em Profundidade

Figura 4.1: Taxonomia das Redes P2P. Adaptado de Ranjan et al. (2006)

Como os nodos que compe uma rede P2P podem ser organizados logicamente, os mesmopodem utilizar duas categorias bsicas (Milojicic et al., 2002): estruturadas e no estruturadas.

Um sistema no estruturado descrito por um modelo de ligaes aleatrias que so ba-seadas na popularidade das informaes de cada nodo (Ranjan et al., 2006). Neste modelo noexiste uma preocupao em criar e manter uma organizao lgica (Milojicic et al., 2002). Soexemplos de sistemas no estruturados o Napster, Gnutella e Kazaa.

J os sistemas estruturados so caracterizados por um modelo de ligaes que segue umadeterminada hierarquia, como a apresentada pelo DHT (Ranjan et al., 2006). Alm de seguiruma hierarquia, os sistemas estruturados se preocupam em manter uma organizao lgica de-nominada overlay (rede de sobreposio) (Jin et al., 2008). Essa organizao mantida paraque a busca por um recurso possua o menor nmero de passos dentro da rede de sobreposio.So exemplos de sistemas estruturados o CAN, Pastry, Chord e Tapestry (Schmidt e Parashar,2005).

A organizao dos dados segue o modelo da organizao da rede (Ganesan et al., 2004). Sea rede for no estruturada, significa que os nodos no faro parte de uma topologia especficae nem de um domnio especfico uma vez que os dados so espalhados pela rede de formaaleatria.

No modelo estruturado, os dados so organizados na rede seguindo uma topologia es-pecfica que depende da rede de sobreposio. Essa caracterstica utilizada para limitar acomplexidade da busca, balanceamento de carga e limitao na sobrecarga do gerenciamentoda localidade dos dados (Ganesan et al., 2004).

30 4.3. P2P

Os dados podem ser as informaes referentes aos nodos, como capacidade de processa-mento e armazenamento, ou arquivos e esses dados formam a hash que utilizada para localizaroutros nodos dentro da rede (Bienkowski et al., 2005).

A consulta e o roteamento so relacionados forma como a rede estruturada. Normal-mente as redes no estruturadas utilizam tcnicas como busca em largura e profundidade nabusca por um determinado recurso (Androutsellis-theotokis e Spinellis, 2004).

J as redes que utilizam sistemas estruturados possuem um sistema de busca que utilizaa hierarquia da rede (Ganesan et al., 2004). Esse mtodo proporciona o controle de carga noroteamento, uma vez que cada nodo recebe aproximadamente o mesmo nmero de consultas emantm um nmero limitado de informaes sobre os nodos da rede. As informaes que umnodo mantm se referem apenas aos nodos mais prximos a ele (Ganesan et al., 2004).

4.3.2 Redes de Sobreposio

As redes de computadores possibilitam a troca de informaes entre dois ou mais nodos,geograficamente separados, sem uma conexo direta entre eles. A infraestrutura de comunica-o deve oferecer meios para conduzir os dados entre a origem e o destino (Tanenbaum, 2003).

Segundo Tanenbaum (2003), uma das principais funes da camada de rede (pilha de pro-tocolos do TCP (Transmission Control Protocol) e IP (Internet Protocol) TCP/IP) realizar oroteamento dos pacotes IP, permitindo que um dado seja transmitido entre um nodo origem aum nodo destino independentemente do trajeto fsico a ser percorrido.

Devido a essa caracterstica oferecida pela pilha TCP/IP possvel ter mecanismos de ro-teamento na camada de aplicao, que operam de maneira totalmente separada dos mecanismossituados na camada de rede (Coulouris e Dollimore, 1988). Esse mecanismo chamado de ro-teamento com redes overlay ou redes de sobreposio. Visto que o roteamento realizado nacamada de aplicao, uma vez definido o endereo de rede do nodo para o qual uma mensagemdeve ser enviada, os mecanismos de roteamento da camada de rede so utilizados e processadosnormalmente (Coulouris e Dollimore, 1988).

Como as redes de sobreposio so topologias lgicas, alguns sistemas P2P utilizam suaprpria topologia lgica para estruturar suas respectivas redes como o caso do Chord (Stoicaet al., 2001), Pastry (Rowstron e Druschel, 2001) e CAN (Ratnasamy et al., 2002).

A CAN (Content Addressable Network) organiza um espao lgico multidimensional decoordenadas, que dividido em zonas. Cada zona atribuda a um participante e conformeos participantes vo entrando na rede, as zonas vo sendo divididas entre os participantes. AFigura 4.2 representa a diviso das coordenadas utilizadas pela CAN.

Como apresentado na Figura 4.2, conforme os nodos forem entrando na rede eles so alo-cados de acordo com a proximidade aos outros nodos na rede formando um plano multidimen-sional (Ratnasamy et al., 2002).

CAPTULO 4. COMUNICAO NAS NUVENS 31

9

10

11

12

13

14

25

Figura 4.2: Espao de Busca da CAN. Adaptado de Ratnasamy et al. (2002).

Diferente da CAN, o Chord apresenta uma organizao lgica dos nodos em forma de anel(Stoica et al., 2001). O Chord distribui as chaves entre os nodos de forma balanceada, atri-buindo o mesmo nmero de chaves para cada nodo existente na rede. Uma vez que as chavesso distribudas de forma balanceada, os elementos de dados associados s chaves so, conse-quentemente, distribudos de maneira que a carga entre os nodos seja balanceada (Stoica et al.,2001).

Como apresenta a Figura 4.3, a rede de sobreposio formada pelo Chord consiste em umanel. Quando um nodo entra na rede, atribudo a ele um identificador (ID) que normalmente formado pela descrio do recurso que ele possui e sua localidade. De acordo com esse ID, onodo disposto em relao aos nodos que possuem IDs prximos ao dele, facilitando assim abusca por um recurso (Stoica et al., 2001).

Figura 4.3: Espao de Busca do Chord. Adaptado de Stoica et al. (2001).

Na rede Pastry, cada nodo na rede possui um identificador numrico nico nodeid. Um nodoenvia mensagens para o nodo que possui o nodeid mais prximo ao seu.

Para minimizar a distncia percorrida pelas mensagens considerada a localizao da redede acordo com a mtrica de proximidade utilizada, que pode ser o nmero de saltos no rotea-mento ou o endereo IP de cada nodo (Rowstron e Druschel, 2001).

32 4.4. ROTEAMENTO P2P EM SISTEMAS DISTRIBUDOS

Figura 4.4: Espao de Busca do Pastry. Adaptado de Rowstron e Druschel (2001).

A Figura 4.4 apresenta a topologia que utilizada pelo Pastry. Nessa topologia, a busca realizada como a busca em uma rvore. Quando um nodo entra na rede, assim como nas outrasabordagens, gerada um identificador (ID) que relacionado ao recurso que ele possui e sualocalizao. Com base no ID gerado, o nodo atribudo a uma rvore, de forma a ficar prximoaos nodos com recursos semelhantes ou localidades prximas.

De acordo com Ranjan et al. (2006), as caractersticas de entrada e sada de nodos da redepassam pelos mesmos procedimentos e o que diferencia uma abordagem da outra a formacomo a busca realizada e a topologia que adotada. Sendo assim, quando um novo nodo entrana rede P2P, preciso que o novo nodo conhea algum nodo que j esteja participando dessarede, para que esse nodo, j participante, seja sua "porta de entrada" para a rede (Ratnasamy etal., 2002).

Uma vez que o novo nodo obtm sua zona na rede, necessrio realizar o ajuste das tabelasde roteamento. Para isso, o novo nodo observa a tabela de roteamento do nodo pr-existentee verifica, dentre os participantes, quais so as entradas referentes aos seus vizinhos. Essasentradas so retiradas da tabela do nodo pr-existente e inseridas na tabela do novo nodo, o qualadiciona ainda uma entrada para o nodo pr-existente (Ratnasamy et al., 2002) (Rowstron eDruschel, 2001). Aps esse procedimento a tabela de rotas atualizada. Quando o nodo sai darede a tabela de rotas deve ser atualizada novamente para manter a consistncia da rede (Stoicaet al., 2001).

4.4 Roteamento P2P em Sistemas Distribudos

Como apresentado na seo anterior, os sistemas P2P estruturados podem ser utilizados noencaminhamento e descoberta de recursos e servios. Essa caracterstica facilitou a adoo desistemas P2P para roteamento em sistemas distribudos.

Em Spence e Harris (2003) proposta uma extenso de um sistema baseado em Pastry paraum sistema de busca. O sistema de busca proposto trabalha em conjunto com o XenoServer

CAPTULO 4. COMUNICAO NAS NUVENS 33

para a busca de nodos baseados em atributos como: localizao topolgica e atributos de QoS.A busca dividida em vrias dimenses. Em cada dimenso, de forma lgica, a busca pelasinformaes dos recursos feita utilizando um modelo de rvore, onde as folhas so os Xeno-Servers (Spence e Harris, 2003).

Em Tam et al. (2004), apresentada uma aplicao de troca de mensagens baseada emPastry. O modelo proposto define diferentes esquemas para a publicao e subscrio de men-sagens para vrios domnios como bolsa de valores e mercados de leilo. O modelo procede aoprocesso de inscrio para um evento atravs de uma rvore de nodos que possuem os mesmosinteresses. A raiz da rvore o nodo que publica a inscrio e os nodos que iro se inscreverso as folhas da rvore (Tam et al., 2004).

Cai et al. (2004) apresenta uma abordagem para habilitar um componente de computaoem grade denominado General Resource Information System (GRIS). Esse componente utilizauma topologia em anel (Chord) para o gerenciamento de recursos gerais relacionados a gradescomputacionais. O modelo apresentado por Cai et al. (2004) faz o mapeamento dos valores dosatributos utilizados na busca por um recurso utilizando uma localidade uniforme.

Triantafillou e Aekaterinidis (2004) prope um sistema de inscries baseado em CAN.Cada evento a ser publicado mapeado para uma regio da CAN, nesse modelo a regio quefoi mapeada fica conhecida como o ponto do evento ou a zona de evento. Todos os pares quefizerem parte da regio do evento so notificados sobre ele. Assim como o sistema apresentadopor Tam et al. (2004), o objetivo diminuir os passos na inscrio para um determinado evento.

Yong Meng et al. (2005) prope o uso de um GRIS baseado em Chord. Nesse trabalho, oGRIS atua como um metaescalonador que mantem informaes relacionadas a cada domnio ecada domnio possui seu escalonador local. A busca por um recurso baseada no sistema Chorde as IDs so geradas de acordo com a descrio do recurso e o servidor que o possui, evitandoassim a gerao de chaves repetidas.

Cheema et al. (2005) apresenta um GRIS que utiliza o Pastry como padro de roteamento.Trs heursticas diferentes so propostas para esse GRIS: busca de uma s vez (one shot), buscarecursiva e busca paralela. A primeira baseada no recurso local para saber a disponibilidade decada escalonador local, a segunda baseada na busca pelo recurso mais prximo ao solicitantee a terceira baseada em vrias buscas j com o conhecimento da localidade do recurso para aexata alocao baseada nos parmetros da requisio do solicitante (Cheema et al., 2005).

Com o surgimento da computao em nuvem algumas abordagens utilizadas em computa-o em grade foram absorvidas por esse modelo computacional. Em Lai et al. (2010) propostouma estratgia de descoberta de recursos em computao em nuvem utilizando sistemas P2P. Aproposta desse trabalho utilizar o sistema Chord (Stoica et al., 2001) na descoberta de recursosem nuvem. Nesse trabalho os autores sugerem uma modificao do Chord para funcionar commais de um anel.

34 4.5. MODELO DE COMUNICAO DO MACC

Lai et al. (2010) prope a criao de novos anis baseados nas regies de cada solicitante.Lai et al. (2010) usa as descries dos servios para a construo da topologia. A vantagem dotrabalho de Lai et al. (2010) o uso de vrios atributos na construo dos IDs dos nodos.

Ranjan et al. (2010) prope o uso de sistemas P2P para o provisionamento de recursos danuvem como a descoberta de servios e o balanceamento de carga. Os autores consideramque a interconexo dos sistemas que compe a nuvem (servidores, mquinas virtuais (VMs),servios de aplicao), utilizando sistemas P2P, pode evitar os problemas de provisionamentode recursos e evitar possveis gargalos e problemas de ponto nico de falha.

Dentre as trs camadas que compe a nuvem, IaaS, PaaS e SaaS, os autores sugerem quea comunicao P2P deve estar na camada PaaS para possibilitar a comunicao das mquinasvirtuais dentro do data center. Foi utilizado o sistema P2P Pastry como sistema base para oroteamento (Ranjan et al., 2010).

Diferente das abordagens apresentadas anteriormente, Zhou et al. (2011) apresenta em seutrabalho uma abordagem P2P hbrida por considerar que o custo de manuteno das redes desobreposio muito alto e pode causar sobrecarga nas atividades de descoberta de servios.Zhou et al. (2011) utiliza o conceito de supernodes para a manuteno da rede P2P. Assim comoos outros trabalhos relacionados a P2P e nuvem, nenhuma avaliao de desempenho realizadaentre os sistemas P2P.

O presente trabalho de mestrado aborda a avaliao de desempenho entre sistemas P2P parademonstrar qual a diferena entre as abordagens utilizadas. Essa avaliao permite identificarquais as diferenas e possveis gargalos que podem ser proporcionados pelas redes de sobrepo-sio na descoberta d