FUNDAO EDSON QUEIROZ UNIVERSIDADE DE FORTALEZA UNIFOR CENTRO DE CINCIAS TECNOLGICAS CCT CURSO CINCIA DA COMPUTAO

UM ESTUDO SOBRE A ELASTICIDADE DO APLICATIVO UNIFOR ONLINE EM UM AMBIENTE DE NUVEM DE INFRAESTRUTURA

PHILIPP BERNARDINO COSTA

Fortaleza Cear 2011

PHILIPP BERNARDINO COSTA

UM ESTUDO SOBRE A ELASTICIDADE DO APLICATIVO UNIFOR ONLINE EM UM AMBIENTE DE NUVEM DE INFRAESTRUTURA

Monografia apresentada para obteno dos crditos da disciplina: Trabalho de Concluso do Curso do Centro de Cincias Tecnolgicas da Universidade de Fortaleza, como parte das exigncias para graduao no Curso de Cincia da Computao. Orientador: Prof. Dr. Amrico Falcone Sampaio

Fortaleza Cear 2011

UM ESTUDO SOBRE A ELASTICIDADE DO APLICATIVO UNIFOR ONLINE EM UM AMBIENTE DE NUVEM DE INFRAESTRUTURA

Philipp Bernardino Costa

PARECER: ______________________________

DATA: ___/___/____

BANCA EXAMINADORA:

_______________________________________________ Prof. Dr. Amrico Tadeu Falcone Sampaio _______________________________________________ Prof. Dr. Nabor das Chagas Mendona

Dedico esta graduao aos meus pais, que me deram amor, apoio moral e espiritual, para chegar at aonde cheguei. Eu acredito em intuio e inspirao. A Imaginao mais importante do que o conhecimento. O conhecimento limitado, enquanto a imaginao abrange um mundo e estimula o progresso, abre asas para evoluo. A rigor um fator real para a pesquisa cientfica. Albert Einstein.

AGRADECIMENTOS

A Deus, por todas as oportunidades na vida, pelo amparo nos momentos de dificuldades, por ter me dado perseverana em buscar meus objetivos e pela sorte de nascer numa famlia maravilhosa. Aos meus pais Ruth e Facundo, por ter me dado todo amor, incentivo, orientao e dedicao, me servindo de parmetro por serem seres humanos excepcionais. Ao meu orientador, Prof. Amrico Falcone Sampaio, pela pacincia, como tambm pela compreenso e disposio de ter me orientado nesse trabalho. A todos os professores que tive aula, pelo o qual passaram um pouco da sua personalidade, experincia de vida e sabedoria, alm da ateno oferecida. Aos bastados inglrios, equipe de Suporte e Infraestrutura do Ncleo de Aplicao em Tecnologia da Informao (NATI), como tambm a todos os colaboradores dessa empresa, que me ajudaram no desenvolvimento desse trabalho. A todos os amigos, que estiveram presentes durante essa caminhada, me dando apoio para a concluso desse trabalho.

RESUMO

O objetivo desse trabalho fazer uma explanao sobre o assunto de computao em nuvem, assim como aprofundar sobre os conceitos de elasticidade. O trabalho visa demonstrar o desempenho do aplicativo UNIFOR Online, simulando diversas quantidades de usurios online, sobre as diversas configuraes de mquinas virtuais, fazendo uso da ferramenta JMeter. No final do processo, ser feito uma anlise detalhada dos resultados produzidos pela ferramenta JMeter, em relao ao cenrio de teste executado. Com isso ser avaliado, qual o melhor tipo de instncia, sobre cada composio de arquitetura, sendo definida pelo estudo de caso. Palavras-chave: Computao em nuvens, Nuvens de Infraestrutura, KVM, OpenNebula, JMeter, UNIFOR Online.

LISTA DE F IGURAS

Figura 1 Arquitetura em computao em nuvem (ZHANG, 2010). ...................................... 16 Figura 2 A Empresa pode adotar uma nuvem privada, pblica ou hbrida. .......................... 18 Figura 3 Visualizao dos modelos de elasticidade .............................................................. 23 Figura 4 Exemplo de arquitetura que realiza elasticidade horizontal. ................................... 23 Figura 5 Em ambas as camadas de container e de banco de dados esto replicadas, para suportar a escalabilidade horizontal (VAQUERO, 2011). ....................................................... 25 Figura 6 Viso geral da plataforma RightScale ..................................................................... 29 Figura 7 O usurio gerencia uma infraestrutura heterognea de computao em nuvem, atravs da plataforma Claudia (RODERO-MERINO et al., 2010). ......................................... 32 Figura 8 Modelo da arquitetura do aplicativo UNIFOR Online. ........................................... 36 Figura 9 Representao do ambiente computacional de uma nica mquina fsica. ............. 38 Figura 10 Representao da rvore de execuo do cenrio de teste: consultar dados ......... 44 Figura 11 Quantidade de usurios com sucesso de execuo para cada instncia AU. ........ 45 Figura 12 Quantidade de usurios com sucesso de execuo para cada instncia ANU. ..... 47

LISTA DE TABELAS

Tabela 1 Associando cada AU com seu respectivo tipo de instncia .................................... 42 Tabela 2 Associando cada ANU com seu respectivo tipo de instncia. ................................ 42 Tabela 3 Quantidade de usurio que no obtiveram sucesso, com o tipo AU. ...................... 45 Tabela 4 Quantidade de usurio que no obtiveram sucesso, com o tipo ANU.................... 47

SUMRIO

INTRODUO ........................................................................................... 11 1. COMPUTAO EM NUVEM ................................................................. 14

1.1. INTRODUO ........................................................................................................... 14 1.2. ARQUITETURA EM COMPUTAO EM NUVEM ............................................... 16 1.2.1. Modelo em camadas da computao em nuvem ................................................... 16 1.2.2. Tipos de nuvens ..................................................................................................... 18 1.3. VANTAGEM E DESVANTAGEM DO USO DA NUVEM....................................... 19

2. ELASTICIDADE EM COMPUTAO EM NUVEM............................... 21

2.1. INTRODUO ........................................................................................................... 21 2.2. TIPOS DE ELASTICIDADE ....................................................................................... 22 2.2.1. Elasticidade do Servidor ........................................................................................ 22 2.2.2. Elasticidade da Plataforma .................................................................................... 24 2.2.2.1. Escalabilidade em nvel de container ............................................................ 25 2.2.2.2. Escalabilidade em nvel de banco de dados .................................................. 26 2.2.3. Elasticidade da Rede.............................................................................................. 27 2.3. FERRAMENTAS PARA AUTO-SCALING ............................................................... 28 2.3.1. Plataforma RightScale ........................................................................................... 28 2.3.2. Amazon Auto Scaling............................................................................................ 31 2.3.3. Plataforma Claudia ................................................................................................ 31

3. ESTUDO DE CASO ................................................................................. 34

3.1. INTRODUO ........................................................................................................... 34 3.2. APLICAO UNIFOR ONLINE ............................................................................... 34

3.3. METODOLOGIA ........................................................................................................ 37 3.3.1. Ambiente Computacional ...................................................................................... 37 3.3.2. Ferramentas ........................................................................................................... 38 3.3.2.1. OpenNebula ................................................................................................... 38 3.3.2.2. Apache JMeter ............................................................................................... 40 3.3.3. Modelagem do Teste ............................................................................................. 41 3.3.3.1. Composio das Mquinas Virtuais .............................................................. 41 3.3.3.2. Cenrio Consultar Dados............................................................................... 43 3.4. RESULTADOS E EXPLICAO DOS TESTES ...................................................... 44 3.4.1. Anlise dos resultados para Arquitetura Unificada (AU)...................................... 45 3.4.2. Anlise dos resultados para Arquitetura No Unificada (ANU) ........................... 47

CONCLUSO ............................................................................................. 50 REFERNCIAS BIBLIOGRFICAS ........................................................... 52

11

INTRODUO

A computao em nuvem tem surgido como um novo paradigma, se fundamentando numa evoluo de uma variedade de tecnologias, tendo como principal objetivo alterar a abordagem da infraestrutura de TI 1 em uma organizao empresarial. Esse novo paradigma foi adotado por diversas empresas como: Salesforce.com 2 , Google App Engine 3 , Amazon Web Services 4 , dentre outras. As empresas que foram respectivamente citadas nessa ordem, provm para seus consumidores, servios de software, plataforma e infraestrutura de computao em nuvem. A pesquisa em computao em nuvem possui alguns desafios que precisam ser mais bem explorados, conforme descrito em (ZHANG, 2010): Gerenciamento automtico da elasticidade de aplicaes; Migrao de mquinas virtuais entre diferentes provedores de nuvens; Gerenciamento eficiente da energia do Datacenter; Segurana das mquinas virtuais dos consumidores; Gerenciamento e armazenamento dos dados. Este trabalho tem como objetivo de investigar um tema de interesse comum aos pontos mencionados acima, que est diretamente relacionado com o comportamento de aplicaes reais em um ambiente de nuvem real. Para isto, este trabalho prope um estudo do aplicativo UNIFOR Online tendo, como meta, analisar o desempenho desse aplicativo sobre diferentes perspectivas de configurao da sua arquitetura, em uma nuvem privada.
1 2

Tecnologia da Informao se limita ao conjunto de atividades que abrange o uso de recursos computacionais. http://www.salesforce.co m/br/?ir=1 3 http://code.google.com/appengine/ 4 http://aws.amazon.co m/

12

Este perfil 5 de aplicao normalmente acarreta desafios relacionados ao seu dimensionamento em termos de infraestrutura. Por exemplo, caso o fornecedor do aplicativo superestime a demanda dos seus recursos, fazendo um grande dimensionamento da infraestrutura (overprovisioning), isto implicar em um maior custo financeiro, por deixar recursos ociosos na nuvem. Caso contrrio (underprovisioning), a aplicao no ir atender a demanda dos seus usurios, resultando em perdas financeiras e danos reputao da empresa. No entanto, para oferecer mecanismos que ajustam as necessidades do aplicativo, de acordo com a demanda imposta pelos usurios, fundamental entender o comportamento desse aplicativo, em relao ao ambiente de computao em nuvem. Por isto, neste trabalho ser desenvolvido um estudo sobre o aplicativo UNIFOR Online que executar dentro de uma nuvem de infraestrutura privada. Esse estudo procura cumprir com os seguintes pontos: Gerenciar a infraestrutura computacional disponvel, usando o gerenciador de nuvem do OpenNebula 6 . Dispor o aplicativo do UNIFOR Online, sobre configuraes homogneas e heterogneas, em relao s instncias de mquinas virtuais. Aplicar um cenrio de teste, usando a ferramenta do JMeter, para cada variao de: quantidade de usurios e configuraes de instncias de mquinas virtuais. Mostrar os resultados do teste e analisar seus resultados. Espera-se que estes resultados possam servir para entender o comportamento do UNIFOR Online em um ambiente de nuvem elstico. No primeiro captulo ser apresentado um embasamento terico sobre Computao em Nuvem, mostrando as principais ideias sobre o tema. Sero abordadas as camadas de servio de uma nuvem, os tipos de nuvens, vantagem e desvantagem do uso da nuvem e dentre outros assuntos. No segundo captulo ser apresentada uma fundamentao terica sobre Elasticidade em Computao em Nuvem, mostrando as principais ideias do tema, trabalhos e ferramentas relacionados. No terceiro captulo ser exibido o estudo de caso da aplicao do UNIFOR Online, juntamente com as ferramentas do OpenNebula e JMeter. Em seguida ser exibida a metodologia do teste, que envolve a modelagem deste usando a ferramenta do JMeter, sendo
5 6

Aplicaes web compostas por multicamadas. http://opennebula.org/

13

aplicada sobre as diferentes configuraes de mquinas virtuais. No final do captulo sero apresentados os resultados e a concluso desse teste. No quarto e ltimo captulo, ser apresentada a concluso desse trabalho, de acordo com os resultados produzidos pela execuo dos testes.

14

1. COMPUTAO EM NUVEM

1.1. INTRODUO

A computao em nuvem um modelo que decorreu dos diversos avanos tecnolgicos, principalmente na rea de hardware (processamento, transmisso e armazenamento dos dados), e software (virtualizao e sistemas distribudos). O conceito de computao em nuvem permite que os recursos computacionais estejam disponveis no ambiente de forma ubqua atravs da internet. Os dispositivos com acesso a internet podero usufruir do uso desses recursos, para estender, por exemplo, s ua capacidade de processamento. A computao em nuvem no est apenas atrelada a dispo nibilidade de recursos fsicos, mas tambm promete mudar a maneira de desenvolver aplicaes e expor servios na internet. A computao utilitria um dos principais conceitos da computao em nuvem, porque os recursos computacionais (de hardware, software e servios de plataforma) sero cobrados pela provedora da nuvem, com base no uso do servio, similarmente a uma empresa de energia eltrica. Segundo (FOSTER et al., 2008) a computao utilitria no necessariamente uma nova ideia. De fato, em 1961, o cientista da computao John McCarthy mencionou que A computao deveria algum dia ser organizado como uma utilidade pblica 7 e passou a especular a forma de como isso poderia ocorrer.

Utilidade publica so organizaes que provem servios atravs de uma infraestrutura ex: emp resa de gua, de energia eltrica ou mes mo gs.

15

Uma caracterstica interessante na computao em nuvem da elasticidade da infraestrutura computacional. Considerada como uma caracterstica fundamental para diversos modelos de negcios, por exemplo, comrcio eletrnico, redes sociais, etc. Caso a empresa de comercio eletrnico precise provisionar mais recursos para atender o excedente de acessos e no deixar de fazer negcios, a soluo desse problema se resolve com uso da elasticidade. Ou seja, pode-se facilmente solicitar e liberar recursos medida que se necessite atender a uma demanda maior ou menor, respectivamente. No captulo dois ser abordado o assunto sobre escalabilidade. Algumas organizaes governamentais e grandes empresas j comearam a investir fortemente no modelo de computao em nuvem, na tentativa de resolver seus problemas, que surgiram na era da Internet, por volta da dcada de noventa (FOSTER et al., 2008). Alguns fatores que contriburam para esse crescente interesse: Reduo do custo do hardware e aumento da fora computacional (processadores multicore) e da capacidade de armazenagem dos dados. Surgimento de aplicaes web 2.0 como: YouTube 8 , Facebook9 , dentre outras, que impem variveis nveis de demanda, em relao ao uso de recursos computacionais. Atratividade do modelo para uso de aplicaes cientficas, no qual se exige mais poder computacional para realizar simulaes, dentre outras atividades cientficas. A vantagem de poder focar no prprio negcio, transferindo para o provedor de nuvem a responsabilidade de realizar a manuteno e o gerenciamento dos servidores, entre outros componentes que compem uma nuvem.

8 9

http://www.youtube.com/ http://www.facebook.co m/

16

1.2. ARQUITETURA EM COMPUTAO EM NUVEM

1.2.1. Modelo em camadas da computao e m nuve m A computao em nuvem composta geralmente por trs camadas (Aplicao, Plataforma e Infraestrutura), no qual cada camada realiza a gerncia dos seus recursos e servios de acordo com a sua responsabilidade. A Figura 1 mostra a formao das camadas, a interao dos servios junto aos usurios, assim como s responsabilidades de cada camada e exemplos de empresas atreladas ao servio.

Figura 1 Arquitetura em computao em nuvem (ZHANG, 2010).

A camada de aplicao oferece um servio de nuvem, denominado como SaaS (Software como um Servio), sendo esta a camada mais alta da arquitetura em computao em nuvem. Nessa camada encontramos servios como: GMail 10 , SalesForce.com, Facebook e entre outros. Diferentemente das aplicaes tradicionais (ao estilo do Microsoft Outlook), as aplicaes na nuvem (GMail), apenas exigem do cliente utilizar um navegador web, para fazer uso de um servio. Os servios so construdos para trazer o melhor desempenho, disponibilidade e reduo do custo operacional envolvido (de licenas de software, por
10

http://mail.google.co m/

17

exemplo). Como desvantagem do SaaS, o cliente fica limitado em customizar o aplicativo para suprir uma determinada demanda no seu negcio. A camada de plataforma dispe de um servio na nuvem, denominado como PaaS (Plataforma como um Servio), em que a provedora da nuvem utiliza de arcabouos (Frameworks) e linguagens de programao especficas para prover este servio. A proposta desse servio auxiliar o cliente no desenvolvimento e na implantao de aplicativos, em nuvens de infraestrutura, sem precisar gerenciar a parte fsica da nuvem. Temos como exemplo de PaaS, o Google App Engine, que possui dois ambientes de desenvolvimento, sendo um baseado em Java e outro em Python, alm do seu arcabouo prprio. O cliente neste caso fica muito amarrado ao uso de tecnologias especficas, que so oferecidas pelo provedor da nuvem, sendo uma grande desvantagem desse tipo de servio. As camadas restantes do modelo so as de infraestrutura e hardware, no qual se dispem como servio de nuvem, denominados de IaaS (Infraestrutura como um Servio). A camada de infraestrutura se baseia na tecnologia de virtualizao, sendo uma camada fundamental para a computao em nuvem, pois nela ocorre um provisionamento fsico dos recursos computacionais, utilizando uma plataforma de virtualizao denominada de hypervisor11 como KVM 12 ou VMWare vSphere Hypervisor 13 . A camada de hardware responsvel pelos recursos fsicos da nuvem, formada por centenas de servidores, organizado em hacks, interconectados, com configurao de tolerncia a falha, dentre outras configuraes e formas de gerncia das mquinas fsicas. As empresas que entregam produtos baseado no IaaS, so a GoGrid 14 , a Amazon Web Service, entre outras diversas empresas. Os clientes desse tipo de servio tm a total flexibilidade em manejar os componentes, instalando e configurando o que desejar, suprindo assim seus requisitos de projeto. O IaaS no prende seus clientes a tecnologias especficas, por exemplo, plataformas de desenvolvimento, banco de dados ou servidores de aplicao especficos. A desvantagem desse tipo de nuvem que para utiliz- la o cliente necessita de maiores conhecimentos tcnicos do que em servios de PaaS e SaaS.

11

Hypervisor u ma tecnologia de virtualizao que permite a criao e o gerenciamento de mquinas virtuais, no qual cada mquina virtual ter u ma configurao de hardware e u m sistema operacional p rprio. Existem duas classificaes de um hypervisor, sendo um tipo que executa bare metal, de forma nativa diretamente no hardware de u ma mqu ina hospedeira e outro tipo que executa em cima de u m sistema operacional hospedeiro. 12 http://www.linu x-kv m.org/page/Main_Page 13 http://www.v mware.co m/products/vsphere-hypervisor/overview.html 14 http://www.gogrid.co m/

18

1.2.2. Tipos de nuvens Existem muitas questes para serem avaliadas pela organizao de TI da empresa. Dentre essas questes, muitas empresas gostariam de classificar a disponibilidade dos seus recursos e servios, num ambiente de computao em nuvem, limitando o acesso de certos usurios. A empresa precisa decidir qual tipo de nuvem (pblica, hbrida e privada) adequada para a sua poltica de organizao, ilustrado na Figura 2.

Figura 2 A Empresa pode adotar uma nuvem pri vada, pblica ou h bri da.

Nuvens pblicas proveem um servio para ser disponibilizado para o pblico em geral. Estas nuvens so hospedadas geralmente fora das instalaes do cliente fornecendo, por exemplo, uma extenso da sua infraestrutura empresarial. O benefcio das nuvens pblicas est em oferecer um rpido provisionamento dos recursos, sem dispor de uma grande quantidade de capital inicial para investir, configurar e manter uma infraestrutura prpria. Outro benefcio repassar a responsabilidade da gerncia da infraestrutura para o provedor da nuvem. Caso um provedor de nuvem pblica deseje disponibilizar um produto, no qual garanta um alto desempenho e uma melhor segurana em computao em nuvem, basta o provedor fazer um isolamento parcial de sua infraestrutura, ou seja, criar um Datacenter virtual privativo, para uso exclusivo de um nico cliente. Este tipo de servio normalmente implica em custos adicionais para o usurio da nuvem.

19

Nuvens privadas tambm so conhecidas como nuvens internas, no entanto, o prprio setor de TI da empresa responsvel pela construo e gerenciamento da nuvem dentro de suas prprias instalaes. As nuvens internas permitem as empresas terem um total controle sobre sua nuvem, porm exige uma expertise para configurar, implantar e controlar o ambiente da nuvem. Para utilizar este modelo a empresa ter que disponibilizar um capital inicial para montar sua nuvem privada e tambm levar certo tempo para configurar e colocar em operao toda a infraestrutura, o que pode ser invivel dependendo da urgncia da empresa. As nuvens hbridas so basicamente a combinao do uso das nuvens do tipo pblica e privada. So utilizadas por empresas que precisam tratar de flutuaes inesperadas de carga de trabalho. Um exemplo de sucesso no uso de nuvem hbrida na hospedagem de jogos online, produzidos e distribudos pela empresa Zynga 15 . Quando lana um novo jogo, a empresa no tem ideia da quantidade de usurios que o utilizaro (no exemplo do jogo Cityville j houve picos de acesso de 90 milhes de usurios). Portanto, a empresa decidiu utilizar a Amazon EC2 inicialmente, at ter uma melhor noo da demanda de usurios que teria este jogo. Somente aps ter maior conhecimento sobre a carga, o jogo passou a funcionar de forma hbrida, onde parte da sua arquitetura distribuda numa nuvem privada (Z-Cloud) e parte na Amazon EC2. Como desafio, as nuvens hbridas introduzem complexidade de como determinar a distribuio de aplicaes sobre ambos os tipos de nuvens privada e pblica (SUN MICROSYSTEMS, 2009).

1.3. VANTAGEM E DESVANTAGEM DO USO DA NUVEM

Um dos grandes benefcios de utilizar a computao em nuvem, ao invs de construir uma infraestrutura prpria de TI, no est nas tecnologias envolvidas em si, mas no fator financeiro da operao. A empresa precisa alocar uma quantia de dinheiro inicial para construir sua infraestrutura prpria de TI, sem contar o fator de depreciao das mquinas com o passar dos anos e custo de pessoal para manter a infraestrutura funcionando, principalmente se for 24 horas por sete dias da semana. Com a computao em nuvem,
15

http://highscalability.co m/blog/2011/5/ 19/ zyngas -z-cloud-scale-fast-or-fail-fast-by-merging-private-an.html

20

precisa-se inicialmente de poucos recursos financeiros para obter uma infraestrutura inicial e pode-se expandir esta infraestrutura medida que for necessrio. A computao em nuvem pode promover um novo cenrio para inovao da tecnologia. Graas ao baixo custo operacional para obteno de uma infraestrutura, pequenas empresas podero focar seus recursos na criao e lanamento de novos produtos de forma eficaz, passando a competir com empresas tradicionais (SUN MICROSYSTEMS, 2009). Um provedor de nuvem normalmente possui diversos Datacenters espalhados pelo mundo, facilitando a penetrao das empresas em mercados distantes de sua origem, porque atravs da nuvem, o servio se encontraria teoricamente mais prximo dos consumidores finais. Essa tendncia est sendo utilizada por servios de jogos online, em que a latncia da rede est correlacionada com a distncia entre o servio e o cliente. Apesar de demonstrar alguns benefcios para adoo da computao em nuvem, ela tambm sofre com alguns entraves, que dificulta a implantao da computao em nuvem nas empresas (ARMBRUST, 2009). Por exemplo, as API 16 de servios de nuvem so proprietrias e torna a migrao de aplicaes para diferentes provedores uma tarefa custosa. Outro obstculo a confiabilidade dos dados, porque uma nuvem pblica poderia sofrer algum tipo de ataque, expondo todos os dados das empresas que esto naquela nuvem pblica. O desempenho em computao em nuvem pode ser imprevisvel, principalmente em ambientes de nuvem do tipo pblica, em que mltiplas mquinas virtuais compartilham a mesma E/S 17 do hardware que elas esto executando. Nestes dois casos as empresas que fornecem servios de nuvem fazem uso das seguintes estratgias, por exemplo, replicao dos dados, utilizao de mltiplos Datacenters e polticas de segurana que ajudam a minimizar o problema de segurana e disponibilidade.

16 17

API significa Interface de Programao de Aplicat ivos E/ S se refere s interfaces de entrada e sada, comu mente usadas por discos rgidos, barramentos PCI, redes ethernet e etc.

21

2. ELASTICIDADE EM COMPUTAO EM NUVEM

2.1. INTRODUO

A elasticidade tambm considerada uma caracterstica importante em computao em nuvem. Os recursos computacionais oferecidos pela nuvem so elsticos, porque seus usurios podem facilmente adquirir mais recursos para atender uma determinada demanda, ou se estiver com excesso de recursos na nuvem, podem fazer sua liberao para minimizar seu custo operacional. A elasticidade tambm trs consigo um potencial para otimizao da produtividade e utilizao de uma infraestrutura, mantendo os nveis de garantia e qualidade de servio, bem como economia dos recursos financeiros (KUPERBERG et al., 2011). O servio bsico de um provedor de IaaS no realiza elasticidade automtica de seus recursos computacionais. No entanto, os provedores de SaaS como de PaaS, realizam a elasticidade automtica de forma transparente para seus usurios. Os provedores de IaaS oferecem uma API para o usurio controlar ou monitorar suas instncias de forma programada. Os usurios tambm podem terceirizar o gerenciamento das nuvens de infraestrutura (automatizar desligamento ou lanamento de novas instncias, dentre outras atividades), atravs de servios como a RightScale 18 , Amazon Auto Scaling19 e etc. A automao feita atravs de regras pr-definidas, no qual tenta-se governar a forma de como o servio escala para cima (provisionando mais recursos) ou escala para baixo (desligando os recursos ociosos) tentando adaptar as variaes de carga das instncias
18 19

www.rightscale.com http://aws.amazon.co m/autoscaling/

22

baseando-se, por exemplo, nas informaes capturadas no monitoramento das mquinas virtuais, entre outras informaes. Alguns sistemas de automao de elasticidade oferecem suporte para o usurio definir suas prprias regras de elasticidade, baseados em condies como uso de memria e CPU (VAQUERO, 2011). Um exemplo de regra simples: executa-se o disparo de uma nova instncia, quando a mdia de uso de CPU nas instncias estiver maior que 85% da capacidade. Os usurios podem tambm produzir regras com maior complexidade, fazendo o uso de frmulas aritmticas ou na combinao de vrias regras simples. Neste captulo, veremos que no existe apenas elasticidade no nvel de servidor, mas tambm existe elasticidade de redes e de plataforma. Tambm veremos algumas ferramentas de elasticidade que sero abordadas nesse captulo.

2.2. TIPOS DE ELASTICIDADE

2.2.1. Elasticidade do Servidor Uma das principais caractersticas das nuvens de infraestrutura (IaaS) a habilidade de realizar tanto elasticidade horizontal quanto vertical. Quando o usurio decide fazer elasticidade horizontal significa que novas mquinas virtuais so adicionadas ao conjunto de instncias, sendo em geral rplicas das instncias que esto em execuo na nuvem ver Figura 3 (a). Por exemplo, algumas arquiteturas como de aplicaes web, precisase de um balanceador de carga para distribuir a carga de trabalho entre todas as rplicas, sendo essas rplicas compostas geralmente, por servidores de aplicao ou servidores web, conforme ilustrado na Figura 4. Nesse exemplo, o DNS tambm faz o papel de balanceador de carga, sobre as diversas rplicas de servidores web. Na elasticidade vertical podem ocorrer mudanas nos recursos destinados para mquinas virtuais, como aumento ou reduo de memria, quantidade de CPU, etc. conforme ilustrado na Figura 3 (b). Infelizmente grande parte dos sistemas operacionais no suporta efetivamente a elasticidade vertical, porque os sistemas operacionais no reconhecem as mudanas dos recursos computacionais, em tempo de execuo, necessitando desligar e religar as mquinas virtuais.

23

Figura 3 Visualizao dos modelos de el asticidade

Figura 4 Exemplo de arquitetura que realiza elasticidade horizontal.

24

A elasticidade do servidor deve prover no

mnimo

ferramentas para

monitoramento e gerenciamento das mquinas virtuais que estejam sendo executada na nuvem. Realizar o monitoramento e gerenciamento de trs mquinas virtuais pode ser considerado uma tarefa de baixa complexidade para o usurio. No entanto, quando se necessita gerenciar dezenas de mquinas virtuais, a complexidade desse tipo de gerenciamento pode crescer demasiadamente, quando o usurio almeja pelo custo timo da plataforma de computao em nuvem. O uso de um Sistema Gerenciador de Escalabilidade (SGE) poderia facilitar na gerncia de dezenas de mquinas virtuais, como tambm automatizar a deciso de quando escalar para cima ou escalar para baixo um servio, que esteja em execuo numa nuvem de IaaS. O desenvolvimento de qualquer SGE est diretamente vinculado com a API do provedor de nuvem IaaS (VAQUERO, 2011). Em geral, os SGEs fazem uso de regras, em que a tomada de deciso depende dos dados, que so providos pelo monitoramento da infraestrutura de computao em nuvem. No entanto, para fazer uma automao completa da elasticidade em aplicativos web, o SGE precisa ter acesso s funcionalidades do balanceador de carga (adicionar ou remover mquinas), para mant- lo atualizado de quantas instncias esto em execuo na infraestrutura de computao em nuvem. Os provedores de nuvem, por exemplo, a Amazon, desenvolveram servios similares como o Elastic Load Balance
20

, em que seu balanceador de carga realiza a deteco

das mquinas virtuais instanciadas, de forma automatizada. No entanto, a Amazon no oferece mecanismo para escalar o prprio sistema balanceador de carga (VAQUERO, 2011). O cliente tambm poderia usar instncias da prpria nuvem, servindo como balanceador de carga, ou mesmo usar um hardware especfico para balanceamento de carga, ideal para ambientes de nuvens hbridas.

2.2.2. Elasticidade da Plataforma Os provedores de nuvem que oferecem o PaaS (a plataforma como servio) disponibilizam para o usurio um ambiente de desenvolvimento todo configurado e preparado para execuo de aplicativos. O usurio precisa apenas focar na programao de seus componentes, fazendo o uso das tecnologias disponveis pelos PaaS.
20

http://aws.amazon.co m/elasticloadbalancing/

25

Uma plataforma de PaaS se fundamenta em duas camadas conhecidas como: container, para execuo do aplicativo (formado pelo servidor de aplicao) e sistema gerenciador de banco de dados, onde iro ser persistidos os dados desse aplicativo. A Figura 5 mostra uma viso geral de uma possvel arquitetura de um provedor PaaS.

Figura 5 Em ambas as camadas de container e de banco de dados esto replicadas, para suportar a escalabili dade horizontal (VAQUERO, 2011).

Tem-se que ter em mente que um provedor de PaaS no se limita em oferecer apenas duas camadas de controle para os usurios. No caso do servio da Microsoft Azure21 , ela oferece outras camadas e servios, por exemplo: comunicao de componentes na nuvem pblica e privada, controle de acesso e identidade, dentre outras funcionalidades.

2.2.2.1. Escalabilidade em nvel de container Diversas formas existem para acomodar os usurios aos containers. Dentre estas formas est uma na qual cada usurio executa seu aplicativo num container exclusivo,

26

abordagem provavelmente utilizada pelo Google App Engine (GAE). Outra forma seria vrios usurios usando o mesmo container, conhecido por multitenant, sendo esta ltima mais econmica e escalvel, na tica do provedor de PaaS. No entanto, para ambos os casos descritos anteriormente, para ocorrer escalabilidade em nvel de container, precisa o provedor sempre instanciar novos containers, em que os componentes do usurio iro executar nas diversas rplicas instanciadas. Como o provedor de PaaS omite do usurio a gerncia das mquinas virtuais, isso dever ser feito de forma transparente pela plataforma. H algumas complicaes para os desenvolvedores, no qual o projeto do aplicativo precisa estar alinhado com a plataforma, por exemplo, no GAE recomendado que os componentes sejam stateless 22 . Para facilitar o desenvolvimento do aplicativo, o suporte para componentes stateful23 deve ser gerenciado e oferecido pelo provedor de PaaS. No caso de componentes stateful, o balanceador de carga e o gerenciador de rplicas devem estar cientes do estado dos componentes (VAQUERO, 2011). Existem diversos mecanismos para manter as diversas rplicas com o estado sincronizado dos componentes. Dentre esses mecanismos, pode-se citar: soft state replication 24 e memcached25 que fazem o compartilhamento explcito dos dados entre as rplicas. Cada soluo comentada anteriormente ir impactar no desenvolvimento dos componentes de diferentes maneiras (VAQUERO, 2011).

2.2.2.2. Escalabilidade em nvel de banco de dados Existe muita pesquisa sobre a escalabilidade de banco de dados, principalmente realizada pelas grandes empresas e comunidades de software livre do setor. Aplicar estratgias de escalonamento em banco de dados fundamental para servios de PaaS, porque espera-se um grande volume de transaes, sendo em geral proporcional a quantidade de aplicaes hospedadas no PaaS. Os provedores de PaaS podem usar diversos mecanismos como sistema de cache (exemplo do memcached) para armazenar os dados que so frequentemente acessados do
21 22

http://www.microsoft.com/windowsazure/ Os componentes mantm-se instanciados apenas durante um perodo de execuo. 23 Os componentes mantm-se instanciados durante toda a execuo. 24 http://research.microsoft.com/en-us/um/people/maheshba/papers/tempestdsn.pdf 25 http://code.google.com/ intl/pt-BR/appengine/docs/python/memcache/overview.ht ml

27

banco de dados. No entanto, dependendo da natureza da aplicao, o uso desse artifcio pode levar a uma perda de desempenho, por exemplo, de uma aplicao, em que seus usurios pouco reutilizam consultas feitas ao banco. No caso do GAE so oferecidos como servio de cache, os componentes de memcached para a plataforma Python e de JCache 26 para a plataforma Java. H outro mecanismo baseado no armazenamento de dados de forma no relacional, conhecidos como sistemas NoSQL 27 . Esses gerenciadores de banco de dados tm como objetivo oferecer alta disponibilidade e alta escalabilidade, sendo muito propcios para utilizao em ambientes de computao em nuvem, tendo como exemplo o Amazon SimpleDB28 , entre outros. A desvantagem desses sistemas que eles ainda no so completamente compatveis com o conceito de transaes ACID 29 . A plataforma Microsoft Azure utiliza a prpria Microsoft SQL Server30 como gerenciador de banco de dados relacional. No servio da Microsoft, o banco de dados pode ser configurado no formato de cluster, provendo um melhor desempenho, como tambm uma melhor disponibilidade para o servio de persistncia da plataforma. Um dos grandes problemas no fato de algumas transaes fazerem uso de dados protegidos, deixando esses dados indisponveis para outras transaes (VAQUERO, 2011). Quanto mais transaes de dados protegidos estiverem ocorrendo ao mesmo tempo, maior a quantidade de conflitos para serem resolvidos, reduzindo assim, o desempenho do aplicativo. O uso de banco de dados replicados pode assegurar para o servio, certo grau de escalabilidade e tolerncia falha.

2.2.3. Elasticidade da Rede O balanceador de carga poder no ser o principal gargalo para a elasticidade de um aplicativo. Se, por acaso, uma infraestrutura de rede no for elstica o suficiente, esta tambm poder influenciar negativamente na elasticidade de um aplicativo. A necessidade em dimensionar uma infraestrutura de rede surge com a consolidao dos Datacenters, servindo vrias mquinas virtuais por mquina fsica. Os recursos de rede podero ser virtualizados de duas formas: primeiro usando virtualizao da
26 27

http://code.google.com/ intl/pt-BR/appengine/docs/java/memcache/overview.ht ml Essa sigla significa: no apenas SQL, mais informaes em: http://www.christof-strauch.de/nosqldbs.pdf 28 http://aws.amazon.co m/simpledb/ 29 Essa sigla significa: Atomicidade, Consistncia, Isolamento e Durabilidade. 30 http://www.microsoft.com/sqlserver/en/us/default.aspx

28

camada de protocolos TCP/IP

31

e segundo usando virtualizao da interface Ethernet 32 . No

entanto, ambas as tcnicas fazem uso de VLAN 33 , separando o trfego das mquinas virtuais da mquina hospedeira. Mesmo assim, essa separao no suficiente para manter a elasticidade do aplicativo. A expanso da infraestrutura de rede considerada uma abordagem de alto custo, alm de induzir instabilidade na infraestrutura existente (VAQUERO, 2011). Contudo os provedores de IaaS devem estipular limites de banda, para cada instncia de mquina virtual, porque poderia haver instncias consumindo toda a banda disponvel pela interface fsica de rede, sendo compartilhada por diversas instncias. Esses limites so estipulados e controlados, atravs do uso de tcnicas como slicing, controle de fluxo e limitao distribuda da taxa, tendo como objetivo aumentar o tempo de utilizao da infraestrutura de rede (VAQUERO, 2011). Com o uso dos mecanismos descritos anteriormente, a banda de rede disponvel na nuvem poderia ser alocada dinamicamente para aplicaes que crescem sobre demanda. Todos os usurios se beneficiariam, por pagar apenas pela banda consumida de seu aplicativo. No entanto, existe outra tcnica chamada de multiplexao estatstica, no qual o provedor da nuvem poderia prever alocao de mais banda de rede para uma determinada ap licao, baseado no histrico de utilizao dos recursos de rede (VAQUERO, 2011). Este o caminho trilhado pelos provedores de nuvem, fazendo o uso racional de seus recursos de rede, no qual tentam conhecer e suprir as necessidades dos aplicativos de seus clientes (VAQUERO, 2011).

2.3. FERRAMENTAS PARA AUTO-SCALING

2.3.1. Plataforma RightScale A empresa RightScale possui como principal carro-chefe a ferramenta denominada de Plataforma de Gerenciamento de Nuvem RightScale, suportando diversas nuvens de infraestrutura, como Amazon EC2, GoGrid, dentre outros provedores de nuvens. Essa ferramenta tem como objetivo prover um ambiente produtivo para gerenciamento e
31 32

Conjunto de protocolos de comunicao, co mu mente usado pela Internet. Padro de interface de rede fsica. 33 Rede local v irtual usada para isolar as redes na segunda camada, usando equipamentos do tipo switches.

29

implantao de nuvens pblicas, hbridas e privadas. A arquitetura da plataforma RightScale composta de algumas camadas, como ilustrado na Figura 6.

Figura 6 34 Viso geral da pl ataforma RightScale

A camada de Cloud Management Environment prov para o usurio todas as informaes para projetar, implantar e gerenciar sua nuvem pblica e privada. Essa camada tem suporte para empresas, que possui mltiplos usurios usando esse sistema da RightScale. Com isso a empresa poderia controlar todo o uso do servio e do faturamento de cada conta atravs da emisso de relatrios, como tambm fazer o controle de acesso e permisso, em relao gesto das mquinas virtuais. O servio da camada Cloud Aware ServerTemplates, possui um componente denominado de ServerTemplate, que inicia com uma imagem genrica chamada de RightImage, contendo apenas o sistema operacional instalado minimamente. O usurio pode escolher quais dos softwares que sero instalados dentro de sua imagem (por exemplo, a pilha de software LAPP 35 ), atravs de diversos scripts prontos para uso, denominados de RightScripts. Em resumo, o ServerTemplates tenta facilitar a criao de uma mquina virtual, contendo todos os softwares necessrios para implantao de um determinado servio definido pelo usurio.
34 35

http://www.rightscale.com/products/features/ LA PP significa: Linu x, Apache, Postgres e Python.

30

A camada composta pelo Automation Engine onde a plataforma do RightScale gerencia e monitora a infraestrutura do cliente, adaptando-a as situaes, conforme a ocorrncia de eventos como: mudanas da demanda do sistema, ocorrncia de falha e etc. Essa camada contm as funcionalidades de notificao e elasticidade, que utilizam os dados coletados pelo sistema de monitoramento da infraestrutura. Um cliente pode definir a lguns eventos com base em mtricas, por exemplo: tempo, memria usada, operaes de entrada e sada de disco, dentre outras mtricas; que disparam aes a serem tomadas pelo sistema, sendo exemplificado logo abaixo: Notificar sobre o estado da infraestrutura a cada 30 minutos, enviando um relatrio por email. Notificar por email quando uma nova instncia automaticamente disparada ou desligada pelo sistema de elasticidade. Lanar duas novas mquinas virtuais, quando a carga de CPU das instncias estiver com nvel acima de 80% de consumo. Manter a infraestrutura com no mnimo trs e no mximo quinze instncias. Manter sempre as instncias funcionando apenas dentro do horrio comercial das 8h s 18h. A camada Multi-Cloud Engine a camada mais prxima da infraestrutura de computao em nuvem. Sendo nessa camada que a plataforma RightScale interage com as APIs de cada provedor de IaaS, gerenciando aspectos nicos de cada nuvem. Assim, a plataforma RightScale no ir prender seu cliente ao uso de nenhum provedor especfico, o cliente poder migrar sua infraestrutura para qualquer provedor de nuvem pblica que foi homologada pelo RightScale, como Amazon EC2, Flexiscale, GoGrid, dentre outros provedores. A plataforma RightScale tambm suporta a gesto de nuvens privadas, como no caso do Eucalyptus36 e etc. No entanto, o usurio tem disponvel um ambiente centralizado para gesto de nuvens hbridas usando a plataforma do RightScale. Em resumo, a plataforma do RightScale tenta reduzir o risco da implantao de mltiplas nuvens, atravs da automatizao de diversos processos. Tem como objetivo facilitar a gerncia da infraestrutura de computao em nuvem, diminuindo a carga de responsabilidade dos administradores de sistema.

36

http://open.eucalyptus.com/

31

2.3.2. Amazon Auto Scaling Motivado pelo surgimento de empresas que usavam sua API, para prover servios de escalabilidade em IaaS, a prpria Amazon disponibilizou um servio chamado de Auto Scaling. Este servio apenas est disponvel quando o cliente solicita o uso do Amazon CloudWatch37 . Algumas caractersticas do sistema Auto Scaling: O usurio recebe algumas notificaes quando o Auto Scaling completa alguma ao ou quando o Amazon CloudWatch inicia alguma ao do Auto Scaling. O Auto Scaling pode gerenciar instncias Amazon EC2, mesmo que elas estejam instanciadas dentro de sua nuvem privada, ou mesmo, nos seus clusters de computao de alto desempenho. Escala dinamicamente baseado nas diversas mtricas que foram capturadas pelo Amazon CloudWatch, ou quando o usurio definir um agendamento. As instncias Amazon EC2 so automaticamente desligadas para economizar dinheiro, quando a demanda fica subutilizada. A Amazon menciona as formas que voc pode usar o Auto Scaling, com outros produtos como o Elastic Load Balancing. O Auto Scaling suporta que o usurio defina uma quantidade mnima de instncias para executar seu servio. No entanto, quando o servio ficar sobrecarregado, o Auto Scaling ir provisionar mais recursos, e quando a demanda voltar ao normal ele retornar a essa quantidade mnima. Esse servio conforme mencionado anteriormente, tem apenas a finalidade de automatizar a elasticidade em sua plataforma de IaaS, sendo uma resposta da Amazon aos servios de outras empresas como a RightScale.

2.3.3. Plataforma Claudia 38 A plataforma Claudia um software de cdigo aberto, desenvolvido pela Telefnica I+D 39 , com recursos do projeto FP7 Reservoir 40 e NUBA 41 . Esse projeto tem o
37 38

http://aws.amazon.co m/cloudwatch/ http://claudia.mo rfeo-pro ject.org/ 39 http://www.t id.es

32

objetivo de permitir aos provedores de IaaS automatizar o servio de implantao, provisionamento e escalabilidade de sua infraestrutura de computao em nuvem. Esse software pode ser utilizado para gerenciar diversos servios de nuvens pblicas (como Amazon, GoGrid, Flexiscale e etc.) e servios de nuvens privadas (como OpenNebula, Eucalyptus, dentre outras plataformas), atravs do desenvolvimento de plugins (drivers) que controlam a alocao dos recursos virtuais. A proposta se resume em criar uma nova camada para controlar as diversas infraestruturas de computao em nuvem de forma unificada, a qual ilustrada na Figura 7.

Figura 7 O usuri o gerencia uma infraestrutura heterognea de computao em nuvem, atravs da pl ataforma Claudia (RODERO-MERINO et al., 2010).

A plataforma Claudia foi projetada para evitar o vendor lock-in, usando um gerenciador de infraestrutura (podendo ser o OpenNebula, dentre outros), para alocar e liberar os diversos recursos virtuais, como mquinas virtuais (RODERO-MERINO et al., 2010). Essa plataforma estende as funcionalidades do OpenNebula, aproveitando seu suporte para diferentes fornecedores de nuvens de infraestrutura, deixando assim seus clientes independentes de fornecedor. Os servios na plataforma Claudia so definidos pelo servio de descrio de arquivos, que faz uso do padro OVF 42 . O OVF neutro em relao plataforma e ao
40 41

http://www.reservoir-fp7.eu/ http://nuba.morfeo-p roject.org/ 42 http://www.d mt f.org/standards/ovf

33

fornecedor de computao

em nuvem,

sendo

considerado

um mecanismo

para

empacotamento de Virtual Appliances 43 (RODERO-MERINO et al., 2010). As regras definidas na plataforma Claudia podem ser compostas por diversos modelos, que atuam na automao da elasticidade, podendo ser exemplificadas logo abaixo: Regras que so baseadas no estado da mquina virtual. Regras baseadas no negcio, por exemplo, manter o custo da utilizao das instncias abaixo de R$ 500,00 por ms. Regras sobre os ANS44 do provedor da nuvem. Conforme visto, a plataforma Claudia se mostra como ferramenta alternativa de cdigo aberto, para realizar o auto-scaling em nuvens de infraestrutura. Seus desenvolvedores tiveram cuidado para tratar de questes como vendor lock-in, na tentativa de facilitar a migrao de uma nuvem para outra e fazer uso de padres aberto s como o caso do OVF.

43

So pilhas de software pr-configurados, que podem ser compostas de uma ou mais mquinas virtuais. No contexto de computao em nuvem, u ma Virtual Appliance u m servio para ser imp lantado numa plataforma de computao em nuvem (RODERO-M ERINO et al., 2010). 44 Significa: Acordo de Nveis de Servio, um contrato estabelecido entre o cliente e o prestador de servio. So firmadas as garantias como, tempo de entrega, qualidade da entrega do servio, tempo mximo de indisponibilidade, dentre outros aspectos.

34

3. ESTUDO DE CASO

3.1. INTRODUO

Segundo foi comentado no captulo anterior, existem diversas formas para realizao de elasticidade em computao em nuvem, porm a aplicao deve tambm estar preparada para usufruir dessa caracterstica da nuvem. Neste captulo, ser demonstrada a aplicao UNIFOR Online, bem como um estudo realizado para investigar e testar esta aplicao em uma nuvem IaaS privada. Alm disso, ser mostrada a metodologia adotada para testar o UNIFOR Online, como tambm o ambiente computacional configurado, as ferramentas que foram usadas e a modelagem do teste. No final desse captulo iremos demonstrar os resultados obtidos na aplicao do teste.

3.2. APLICAO UNIFOR ONLINE

Inicialmente, um aplicativo Acadmico foi idealizado e desenvolvido dentro da Universidade de Fortaleza (UNIFOR) a partir de julho de 1989. Visando atender as necessidades da universidade como: realizar matricula de aluno, realizar cadastramento de professores, de disciplinas, dentre outras atividades. No entanto, esse aplicativo entrou em operao no inicio dos anos 90, sendo baseado na arquitetura cliente-servidor, qual era

35

executado dentro de um Mainframe45 alugado pela empresa Bull 46 . Em 1993 foi realizado downsize 47 do Mainframe da Bull para um minicomputador PA-RISC48 . Nesta mesma poca foi adotado o uso de um sistema gerenciador de banco de dados relacional. Em janeiro de 1996 surgiu o aplicativo do UNIFOR Online, inspirado no conceito de aplicao web, como no caso do internet banking do Banco Bradesco, que surgiu neste mesmo perodo. Por volta de 2005 o sistema do UNIFOR Online foi migrado para ser executado em mquinas da arquitetura x86 49 e continuam at o presente momento (2011). A migrao do sistema Acadmico para o sistema do UNIFOR Online est sendo feita de forma gradativa, ao longo dos anos, pois esse sistema Acadmico muito grande e complexo, para ser migrado de uma vez. O aplicativo do UNIFOR Online antes da aquisio de novos servidores era executado diretamente em apenas trs mquinas dedicadas. Sendo assim, nos momentos de pico de uso, o aplicativo chegava a ficar fora do ar, pois estourava a capacidade dos servidores, por causa da alta quantidade de requisies, demandada principalmente no perodo da matricula dos veteranos e na divulgao do resultado do vestibular. Com a aquisio de novos servidores, foi decidido que grande parte dos componentes do UNIFOR Online, como servidores de aplicao e servidores web, seriam instalados em diversas 50 instncias de mquinas virtuais, conforme ilustrado na Figura 8. A plataforma de virtualizao escolhida para o desenvolvimento da nuvem privada do UNIFOR Online foi a plataforma comercial do VMWare vSphere51 .
45 46

http://en.wikipedia.org/wiki/Main frame_co mputer http://www.bull.com/ index.ht ml 47 o processo de migrao de sistemas que rodam em plataforma Mainframe para plataforma de minico mputadores. Essa migrao visa principalmente reduo dos custos de aluguel do Mainframe, atravs da aquisio de minico mputadores. 48 http://en.wikipedia.org/wiki/PA-RISC 49 http://en.wikipedia.org/wiki/ X86 50 Cada instncia de mquina virtual possui informaes prprias de IP fixo, assim co mo configuraes do servidor de aplicao, que depende desse nmero IP. 51 http://www.v mware.co m/products/vsphere/overview.html

36

Figura 8 Model o da arquitetura do aplicati vo UNIFOR Online.

De acordo com modelo acima, primeiro a camada de servidores web compe o ambiente de execuo do portal UNIFOR, qual composto por 2 a 4 instncias de mquinas virtuais. Diversos aplicativos do UNIFOR Online residem na camada de servidores de aplicao. Esta camada tem alta capacidade de ser elstica, no entanto o administrador do sistema precisa definir manualmente a elasticidade durante os perodos de pico. Esta camada composta por um conjunto de 12 a 50 instncias de mquinas virtuais. A terceira camada dos servidores de aplicao PL/SQL, composta por aplicaes legadas (antigo aplicativo Acadmico) do UNIFOR Online, sendo agrupadas dentro de 3 a 5 instncias. E por ltimo, o sistema de banco de dados Oracle est sendo executado em mquinas dedicadas, sendo que todos os servios mencionados anteriormente fazem uso deste mesmo banco de dados. Aps o estabelecimento da nuvem privada do UNIFOR Online, foram realizados diversos testes de estresse. Analisava o desempenho dos servidores de aplicao, de acordo com a variao da quantidade de memria RAM destinada para a execuo da instncia, depois realizava os mesmos testes variando a quantidade de CPU.

37

Durante os testes foram observados que instncias contendo 8 GB de memria RAM, como tambm instncias que tinham mais de um processador, no aumentava m o desempenho 52 do servidor de aplicao, conforme o esperado. Pois, a verso dos servidores de aplicao que foi usada, no comportava fazer gerenciamentos de grandes quantidades de memria RAM. Aps o termino dos testes foi concludo que cada instncia de mquina virtual deveria ter as seguintes configuraes: 2 GB de RAM, 1 CPU virtual e 12 GB de disco virtual, sendo mais que suficiente para executar o aplicativo do UNIFOR Online. Conforme visto anteriormente, a soluo de aplicar a elasticidade horizontal mais adequada para o cenrio de pico de uso53 do aplicativo, do que aplicar a elasticidade vertical. Nesse trabalho ser aplicado um estudo similar ao mencionado anteriormente, no qual iremos dispor os servidores de aplicao do UNIFOR Online sobre diferentes configuraes de mquinas virtuais. Tambm iremos fazer uso de ferramentas e de software livre, para executar este experimento.

3.3. METODOLOGIA

3.3.1. Ambiente Computacional O ambiente computacional composto de trs mquinas fsicas 54 , no qual cada mquina possui instalado o sistema operacional Linux CentOS 55 6 de 64 bits. Os principais softwares instalados nesse sistema operacional foram a plataforma de virtualizao do KVM, como tambm o gerenciador de nuvem de infraestrutura OpenNebula 2.2. O sistema operacional escolhido para executar dentro das mquinas virtuais tambm foi o CentOS 6, por ter melhor compatibilidade com o aplicativo do UNIFOR Online. Todo este ambiente est ilustrado na Figura 9.
52

O desempenho foi mensurado pela capacidade do servidor de aplicao processar e manter as sees de usurio abertas. 53 Esse cenrio refere-se ainda para perodo da matricu la dos veteranos. 54 Tambm podem ser conhecidas como mquinas hosts 55 http://www.centos.org/

38

Figura 9 Representao do ambiente computacional de uma nica mquina fsica.

3.3.2. Ferramentas Esta seco apresenta as ferramentas do OpenNebula e do Apache JMeter, que foram utilizados no desenvolvimento e na execuo desse estudo.

3.3.2.1. OpenNebula O OpenNebula um gerenciador de nuvem baseado em cdigo aberto, cuja a primeira verso foi lanada em Maro de 2008. Surgiu com objetivo de gerir uma infraestrutura computacional em cluster ou datacenter, provendo tambm servios de IaaS, para ambientes de nuvem pblica, privada ou hbrida. Com a instalao desse gerenciador de nuvem, podemos centralizar o controle da infraestrutura computacional, como tambm centralizar o controle do ciclo de vida das mquinas virtuais. As funes do OpenNebula podem ser acessadas atravs de linha de

39

comando (CLI), via linguagem de programao com o uso da API OCCI 56 , ou mesmo, atravs de um painel administrativo web, denominado de OpenNebula Sun-Stone57 . Este painel instalado durante a instalao do OpenNebula e precisa de algumas dependncias extras da linguagem de programao Ruby, como o framework Sinatra58 e o webserver Thin 59 , para poder ser utilizado. As principais funes desse gerenciador de nuvem esto em executar as seguintes funcionalidades: adicionar, remover, alterar e monitorar os recursos computacionais, sendo descritos logo abaixo: Gerenciar mquinas host que contm um hypervisor instalado. Gerenciar infraestrutura de rede composta por virtual bridge. Gerenciar imagens de mquinas virtuais, que podem ser compostas por um sistema operacional pr-instalado ou por imagens vazias, que servem de espao extra para as mquinas virtuais. Gerenciar instncias de mquinas virtuais consiste na atividade de manejar o ciclo de vida (levantar, derrubar, suspender e etc.) da mquina virtual, como tambm, monitora o estado da CPU, memria e trfego de rede da mesma. Uma funcionalidade interessante na gesto de instncias de mquinas virtuais a migrao da mquina virtual de um host para outro. Contudo alguns virtualizadores, por exemplo, do KVM, suportam realizar essa migrao de forma quente, conhecida como live migration. Essa funcionalidade consiste em migrar uma mquina virtual de um host para outro sem suspender seu estado operacional. O requisito para realizar o live migrate, ter uma unidade de armazenamento compartilhado entre os hosts, assim como ter o mesmo hypervisor instalados nas mquinas hosts. No entanto, para criar uma nova instncia de mquina virtual preciso produzir um template, contendo as seguintes informaes: nome, quantidade de CPU, quantidade de memria, selecionar dentre o conjunto 60 de imagens e redes virtuais aquelas que sero utilizadas pela instncia, dentre outras informaes. Aps criar esse template, podemos efetuar a implantao dessa instncia (operao de levantar instncia), em um dos hosts disponveis pelo gerenciador de nuvem.
56 57

http://opennebula.org/documentation:archives:rel2.2:occiu g http://opennebula.org/documentation:archives:rel2.2:sunstone 58 http://www.sinatrarb.co m/ 59 http://code.macournoyer.com/thin/ 60 Esses componentes precisam est previamente cadastradas no gerenciador de nuvem do OpenNebula.

40

Conforme visto, o gerenciador de nuvem do OpenNebula simplifica a gesto dos recursos computacionais, como tambm facilita controlar o ciclo de vida das mquinas virtuais; por causa dessas duas motivaes, o OpenNebula foi usado nesse estudo de caso. Todavia existem outros gerenciadores de nuvem que fazem o mesmo papel do OpenNebula, como o caso do OpenStack61 e do Eucalyptus.

3.3.2.2. Apache JMeter62 O Apache JMeter um completo arcabouo (framework), desenvolvido 100% sobre a plataforma do Java SE63 , sendo originalmente designado para realizar teste de carga e mensurar o desempenho de aplicaes web. Entretanto podemos expandir as funcionalidades desse framework atravs de plugins. Os testes aplicados pelo JMeter consistem em fazer uso de recursos estticos ou recursos dinmicos (Servlets64 , Objetos Java e etc.). Com isso podemos simular diferentes tipos de carga, como tambm diferentes quantidade de acessos concorrentes, atravs da simulao de centenas ou at milhares de usurios, que acessam simultaneamente os servidores web ou servios remotos. No final de cada simulao se produz resultados de desempenho sobre cada uma das perspectivas mencionada. A partir desses resultados, podemos exportar os dados e fazer uma anlise grfica em relao ao desempenho do servidor web ou servio remoto. Com relao aos servios remotos ou servidores web, as requisies feitas pelo JMeter parecem com as requisies de qualquer outro navegador de internet. Nessa ocasio esse aplicativo no pode ser comparado com um navegador de internet, porque o JMeter no realiza as mesmas operaes suportadas pelos navegadores comuns, por exemplo, processamento de Javascript, de CSS, execuo de plugins para contedos Flash e Java Applet, entre outras operaes. Com o JMeter apenas possvel visualizar de forma simples as respostas HTML, que foram produzidas pelo servidor web ou por qualquer outro tipo de servio remoto.

61 62

http://www.openstack.org/ http://jmeter.apache.org/ 63 http://www.o racle.co m/technetwork/java/javase/overview/index.ht ml 64 http://www.o racle.co m/technetwork/java/javaee/servlet/index.html

41

3.3.3. Modelagem do Teste O teste do aplicativo UNIFOR Online foi modelado na ferramenta JMeter. Esse plano de teste ir simular um grupo de usurios na ordem de 500, 1000, 2000, 4000 e 6000, acessando simultaneamente a aplicao do UNIFOR Online. Contudo a mdia diria de acessos simultneos por volta de 1500 usurios online hora, correspondendo menos de 10% dos alunos matriculados na universidade. Foi definido, que a execuo do caso de teste ir ocorrer, trs vezes para cada quantidade de usurio e cada disposio de arquitetura do UNIFOR Online.

3.3.3.1. Composio das Mquinas Virtuais Conforme visto na seco de ambiente computacional, temos disponveis trs mquinas hosts. Duas dessas mquinas sero usadas para executar as instncias das mquinas virtuais e a mquina restante estar dedicada para executar o teste do JMeter, assim como o gerenciador de nuvem do OpenNebula. Uma mquina virtual pode assumir uma das seguintes configuraes de instncia: Small: 1 GB de RAM e 1 CPU virtual. Medium: 2 GB de RAM e 2 CPU virtual. Large: 3 GB de RAM e 4 CPU virtual. Todas as instncias de mquinas virtuais tero 12 GB de HDD virtual, disponvel para realizar suas operaes, alm de ter apenas o servidor de aplicao do aplicativo UNIFOR Online devidamente instalado nesse HDD virtual.

42

Arquitetura Uniforme (AU) formada pela composio de instncias, que possuem configuraes homogneas de mquinas virtuais, demonstrado na Tabela 1. Arquitetura Uniforme AU 01 AU 02 AU 03 AU 04 AU 05 AU 06 AU 07 Mquinas Fsicas HOST 01 HOST 02 HOST 03 JMeter 1 Small JMeter 1 Medium JMeter 1 Large 1 Small 1 Small 1 Medium 1 Medium 1 Large 1 Large 2 Small 2 Small JMeter JMeter JMeter JMeter

Tabela 1 Associando cada AU com seu respecti vo ti po de instncia.

Para cada composio de AU, no ter a necessidade de adotar polticas de distribuio dos endereos IP 65 associados com essas instncias, porque as requisies dos usurios sero distribudas igualmente entre as mquinas virtuais instanciadas. Arquitetura No Uniforme (ANU) composta por instncias, que possuem configuraes heterogneas de mquinas virtuais, conforme demonstrado na Tabela 2. Mquinas Fsicas Arquitetura No Uniforme HOST 01 HOST 02 HOST 03 ANU 01 1 Small 1 Medium JMeter JMeter ANU 02 1 Small 1 Large JMeter ANU 03 2 Small 1 Medium ANU 04 ANU 05 ANU 06 ANU 07 ANU 08 2 Small 3 Small 3 Small 1 Small 1 Medium 1 Large 1 Medium 1 Large 1 Large JMeter JMeter JMeter JMeter JMeter

1 Small 1 Small 1 Medium 1 Medium

Tabela 2 Associando cada ANU com seu respecti vo ti po de instncia.

A composio ANU ter a necessidade de adotar polticas de distribuio dos endereos IP, porque as requisies dos usurios devem ser distribudas ponderadamente de acordo com o tipo de instncia. Por exemplo, s instncias maiores devem receber uma maior carga de responsabilidade, para processar as requisies dos usurios, do q ue s instncias
65

Abreviatura de Internet Protocol, mais in formaes em: http://tools.ietf.org/html/rfc791

43

menores. Sendo assim, para cada instncia da composio ANU, a distribuio dos endereos IP cadastrada no arquivo de configurao pontuada na seguinte forma: Instncia small ter um endereo cadastrado. Instncia medium ter dois endereos cadastrados. Instncia large ter trs endereos cadastrados. Ao levantar mais de uma instncia, por exemplo, AU 04 ou qualquer ANU 0x, elas sero levantadas em diferentes hosts, mantendo assim o equilbrio do ambiente computacional.

3.3.3.2. Cenrio Consultar Dados O cenrio consultar dados tem como objetivo mensurar a capacidade do aplicativo UNIFOR Online, em gerenciar as sesses de usurios, de acordo com as diversas configuraes de mquinas virtuais. Esse cenrio de teste se resume na seguinte ordem de execuo de tarefas: Realizar Login e Consultar Extrato Financeiro, Rendimento de Nota, Histrico e Frequncia do Semestre, no qual essa sequncia ilustrada na Figura 10. Antes da execuo desse cenrio, o JMeter processa 66 as credenciais dos alunos atravs de um arquivo, assim como os endereos dos servidores de aplicao, que estaro online no momento do teste, em outro arquivo. Contudo as polticas de distribuio dos endereos IP associados s instncias de mquina virtuais, foram discutidas na seco anterior. Todos os testes executados nesse experimento representam requisies HTTP 67 , que submetida para o servidor web atravs do mtodo POST 68 desse mesmo protocolo. Entre duas tarefas existe uma pausa de execuo, que definida em milissegundos. A existncia dessa pausa para simular o tempo de permanncia do usurio numa determinada pgina web.
66

O JMeter ir associar para cada usurio virtual u ma linha do arquivo carregado, caso a quantidade de usurios, seja maior que a quantidades de linhas de um arquivo, o JMeter ir fazer u ma leitura circular desse arquivo. 67 http://www.w3.org/Protocols/rfc2616/rfc2616-sec1.ht ml#sec1 68 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.ht ml

44

Figura 10 Representao da rvore de execuo do cenrio de teste: consultar dados

3.4. RESULTADOS E EXPLICAO DOS TESTES

Os testes aplicados para cenrio consultar dados, foram realizados trs vezes, para cada quantidade de usurio e tipo de instncia sendo AU ou ANU. A ferramenta JMeter produziu no final do teste diversos dados. O critrio escolhido foi a taxa de erro69 que serve para avaliar se uma instncia comporta ou no uma certa quantidade de usurios para o qual foi designado. Os resultados produzidos nas tabelas abaixo representa m a mdia aritmtica das trs execues do cenrio de teste, baseando-se no critrio escolhido. Quando uma instncia esgota a sua capacidade de gerenciar as sesses dos usurios, no teste esse esgotamento mostrado com um aumento na taxa de erro, no item realizar login do plano de teste. Com o fracasso desse item, todo plano de teste naturalmente fracassa, pois as requisies restantes, no tero acesso aos outros servios, sendo redirecionados para a pgina de autenticao. No entanto, existem diversos fatores que podem limitar a capacidade de uma instncia, por exemplo, pouco espao livre de memria RAM disponvel na mquina, o banco de dados no comporta abrir milhares de conexes simultneas, entre outros motivos.

45

3.4.1. Anlise dos resultados para Arquitetura Unificada (AU) Nessa seco iremos analisar os resultados dos testes para o cenrio consultar dados, de acordo com conjunto de instncias do tipo AU. A Tabela 3 mostra os resultados, do critrio taxa de erro, relacionando s quantidades de usurios com a composio das diversas instncias.
Quanti dade de Usurio 500 1000 2000 4000 Arqui tetura Uniforme de Instnci as AU 01 0,00% 39,77% 62,50% 73,95% AU 02 0,00% 0,00% 2,97% 1,58% AU 03 0,00% 0,00% 0,00% 0,17% AU 04 0,00% 0,00% 42,17% 58,52% AU 05 0,00% 0,00% 0,12% 2,17% AU 06 0,00% 0,00% 0,00% 1,20% AU 07 0,00% 0,00% 1,65% 41,02%

6000 76,53% 20,25% 1,57% 68,53% 5,58% 1,67% 53,48% Tabela 3 Quanti dade de usurio que no obti veram sucesso, com o ti po AU.

A partir dos resultados expostos pela Tabela 3 foi desenvolvido um grfico, conforme ilustrado pela Figura 11, para demonstrar a quantidade de usurios, que obtiveram sucesso na execuo desse cenrio.
7000 6000 Usurios com Sucesso

5000
4000 3000 2000 500 1000 2000 4000

1000
0 500 1000

AU 01
500

AU 02
500

AU 03
500

AU 04
500

AU 05
500

AU 06
500

AU 07
500

6000

602
750

1000
1941

1000
2000

1000
1157

1000
1998

1000
2000

1000
1967

2000
4000

1042
1408

3937
4785

3993
5906

1659
1888

3913
5665

3952
5900

2359
2791

6000

Tipos de Instncias Figura 11 Quanti dade de usurios com sucesso de execuo para cada instnci a AU.
69

Corresponde quantidade de usurios, que tentaram usar o servio e obtiveram algu ma mensagem de erro, sendo geralmente produzida no servidor. Contudo o erro mais co mu m era o HTTP 500 (erro interno de servidor), no qual o servidor de aplicao no comporta atender todas as requisies dos usurios.

46

Conforme visto na Figura 11, as instncias do tipo AU 01 e AU 04, sendo estas de tamanho small, no so adequadas para executar o aplicativo UNIFOR Online, sob a demanda de 2000 a 6000 usurios online. O cenrio consultar dados mostra que estas instncias trabalham perto do limite operacional mdio de 1500 usurios online simultneos. As instncias compostas pelo tipo AU 07, cobrem essa restrio do limite operacional, todavia esse tipo de instncia consome muito recurso das mquinas host. Existem alternativas que resolve o problema, consumindo metade dos recursos computacionais, por exemplo, da instncia do tipo AU 02. As instncias do tamanho small tendem a ter um baixo desempenho, porque o aplicativo UNIFOR Online precisa de uma mquina com no mnimo 768 MB de RAM, para apenas iniciar o seu servio. Contudo, ao usar uma instncia do tamanho small, sobram em mdia apenas 384 MB de RAM disponvel, para processar todo um volume de requisies, que produzida pelos usurios. Atravs desse fato compreende-se o salto de desempenho entre uma instncia small em relao aos outros tipos de instncia. O aplicativo UNIFOR Online comporta mais usurios, quando se aplica a elasticidade vertical, conforme visto no aumento mdio de 1100 usurios ao passar da instncia do tipo AU 02 para AU 03, sob a demanda de 6000 usurios. Em relao com as demandas inferiores a 6000 usurios, as duas instncias AU 02 e AU 03, tem um desempenho equivalente. Porm no custo e beneficio, considerando o limite operacional mdio, a instncia do tipo AU 02 comporta confortavelmente uma demanda de mais de 4000 usurios, alm de exigir menos recursos da mquina host. O cenrio das instncias AU 05 e AU 06, no qual foi aplicada a elasticidade horizontal sobre as instncias AU 02 e AU 03, respectivamente, no houve nenhum acrscimo significativo, em relao ao desempenho da instncia do tipo AU 03. Apenas sobre o tipo AU 02, que continuou com a mesma diferena de 1100 usurios. Se a mquina disponvel para executar os testes do JMeter, conseguisse comportar uma maior quantidade de usurios, por volta de 10000 usurios, talvez fosse mostrado o real beneficio dessa elasticidade. De acordo com essa seco, a instncia do tipo AU 02 comporta confortavelmente uma demanda de at quatro vezes o limite operacional mdio. No obstante, caso a mquina host que hospede essa instncia, caia por algum motivo, o servio do UNIFOR Online ficaria, nesse caso temporariamente fora do ar. Ento, para garantir um desempenho razovel do aplicativo, como tambm uma maior disponibilidade do servio, o melhor tipo de instncia

47

AU 05. Por consumir menos recursos computacionais em relao ao tipo do AU 06 e ter um melhor desempenho sobre a instncia do tipo AU 07. 3.4.2. Anlise dos resultados para Arquitetura No Unificada (ANU) Nessa seo iremos analisar os resultados dos testes para o conjunto de instncias do tipo ANU, segundo mostrado pela Tabela 4, relacionando s quantidades de usurios com a composio das diversas instncias do tipo ANU.
Quanti dade de Usurio 500 1000 2000 4000 6000 Arqui tetura No Uniforme de Instncias ANU 01 0,00% 29,98% 51,95% 71,00% ANU 02 0,00% 19,60% 41,97% 67,69% ANU 03 0,00% 1,95% 21,95% 55,00% ANU 04 0,00% 0,37% 30,75% 46,88% ANU 05 0,00% 0,00% 1,10% 24,02% ANU 06 0,00% 0,00% 0,00% 16,75% ANU 07 0,00% 0,00% 0,00% 4,03% ANU 08 0,00% 0,00% 0,00% 6,92% 37,45%

78,01% 73,23% 65,30% 58,50% 46,57% 41,60% 36,91% Tabela 4 Quanti dade de usurio que no obti veram sucesso, com o ti po ANU.

A partir do resultado da Tabela 4 foi desenvolvido um grfico, sendo visualizado pela Figura 12, demonstrando a quantidade de usurios que obtiveram sucesso na execuo desse cenrio, em relao s instncias do tipo ANU.
4500
4000

Usurios com Sucesso

3500
3000

2500
2000 1500 1000 500 500

1000
2000 4000 ANU 01 ANU 02 ANU 03 ANU 04 ANU 05 ANU 06 ANU 07 ANU 08 6000

0
500 1000 2000

500
700

500
804

500
981

500
996

500
1000

500
1000

500
1000

500
1000

961
1160

1161
1292

1561
1800

1385
2125

1978
3039

2000
3330

2000
3839

2000
3723

4000
6000

1320

1606

2082

2490

3206

3504

3785

3753

Tipos de Instncias
Figura 12 Quanti dade de usurios com sucesso de execuo para cada instnci a ANU.

48

Os testes realizados para o tipo de instncia ANU esto com os resultados piores, em relao aos mesmos testes realizados para o tipo AU. Porque segundo os analistas de suporte do NATI, os desenvolvedores da empresa estavam executando diversos processos, que causava alta carga de estresse no banco de teste. Resultando assim numa realidade diferente em relao aos testes expostos pela Tabela 3, que executou num ambiente totalmente dedicado. Sendo assim, nesse conjunto de testes ser mantido o parmetro da mdia diria de 1500 usurios hora, porque o sistema do UNIFOR Online deve funcionar para essa quantidade de usurios, independente se o sistema de banco de dados est ou no sobrecarregado. A Figura 12 mostra que o tipo de instncia ANU 01, teve o pior desempenho, em relao a todos os outros tipos de instncia. Com aplicao da elasticidade vertical, de acordo como mostrado pelo tipo ANU 02, houve uma melhora no desempenho em relao ao tipo ANU 01. Essa melhoria tambm tem a ver com adoo das polticas de distribuio dos endereos IP, no qual foi discutido em seces anteriores, sendo adotado para todas as instncias do tipo ANU. No caso do ANU 02 as polticas de distribuio funcionam na seguinte forma, para cada 4 requisies enviadas para esse ambiente, um das requisies era destinado para instncia do tipo small e as outras trs requisies para instncia do tipo large. No entanto, o tipo ANU 02 no teve um resultado satisfatrio, considerando a mdia diria de 1500 usurios online, pois qualquer variao acima dessa mdia pode fazer o servio falhar, ou seja, deixar de atender as requisies dos usurios. As instncias do tipo ANU 03 e ANU 05 so variaes da instncia original do tipo ANU 01, no qual foi aplicada elasticidade horizontal sob a instncia small do conjunto ANU 01. A passagem do ANU 01 para ANU 03 houve um ganho significativo de desempenho, ficando dentro da mdia diria de usurios. Por isso, a passagem da instncia do tipo ANU 01 para ANU 05 dobra a capacidade de suportar as requisies dos usurios, ficando num patamar superior de 3000 usurios online, ou seja, bem acima da mdia diria. Os ganhos notados pela execuo da elasticidade horizontal se devem, pela existncia de mais instncias dividindo a carga de processamento gerada pelas requisies dos usurios. Contudo a diferena das instncias ANU 04 e ANU 06, para as citadas anteriormente est na relao da sua instncia base, que do tipo ANU 02. Toda anlise realizada para as instncias do tipo ANU 03 e ANU 05 pode ser considerado tambm para essas instncias do tipo ANU 04 e ANU 06, em comparao com a instncia base ANU 02. No obstante, o conjunto do tipo ANU 04, tem na sua formao uma instncia do tipo large, essa instncia obtive em geral um desempenho superior, do que a instncia do tipo ANU 03,

49

por ter maior condio de comportar mais usurios online. Porm, para a quantidade de 2000 usurios a instncia do tipo ANU 04 perdeu para ANU 03, isso deve ter sido causado pela variao da carga do banco de teste, causando essa influncia negativa no resultado. Com os resultados da instncia do tipo ANU 06, mostra que a elasticidade vertical em relao instncia do tipo ANU 05, obteve certo ganho de desempenho. Com isso, era preciso ter instncias do tipo extra large e ultra large, para comprovar realmente a eficcia da elasticidade vertical sob o aplicativo do UNIFOR Online. O conjunto de instncia do tipo ANU 07, obteve o melhor desempenho do teste, sendo compostas por todos os tipos de instncias disponveis para compor sua arquitetura de mquinas virtuais. Esse conjunto ANU 07 no representa, entretanto o melhor custo e beneficio, considerando o consumo 70 de recursos computacionais. O segundo melhor conjunto de instncias foi do tipo ANU 08, que ficou levemente atrs em relao aos resultados do tipo ANU 07. Esse tipo ANU 08 composto pela aplicao da elasticidade horizontal completa do conjunto de instncias do tipo ANU 01. Os outros conjuntos como ANU 05 e ANU 06, conseguem estar acima do patamar da mdia diria de usurios online, contudo essas instncias direcionam por volta da metade das suas requisies, para suas instncias do tipo small. Supondo a execuo em condies normais, conforme aconteceu na execuo dos testes para o tipo de instncia AU, esse conjunto de instncias do tipo ANU 05 e ANU 06 no passariam desse patamar de 4000 usurios online. Essas instncias do tipo small por motivos j explicados tendem a produzir uma alta taxa de erro. Podendo assim causar problemas de insatisfao dos usurios, em relao ao servio prestado pelo UNIFOR Online.

70

So mando as configuraes das mquinas virtuais, que compem esse conjunto precisa de: 7 CPU virtual e 6 GB de mem ria RAM.

50

CONCLUSO

Esse trabalho teve como objetivo contextualizar o tema de computao em nuvem e tambm aprofundar sobre os conceitos de elasticidade. Foi mostrado um estudo de caso de uma aplicao real, que aplica um cenrio de teste, em relao s diversas configuraes de mquinas virtuais. A principal contribuio deste trabalho foi estudar e analisar o comportamento da aplicao UNIFOR Online em um ambiente de nuvem privada, no qual foi configurado OpenNebula na infraestrutura do NATI. Um cenrio de teste foi desenvolvido para medir o desempenho de algumas operaes comuns, que so realizadas por usurios do UNIFOR Online, em comparao aos diferentes nveis de carga do sistema. Foram desenvolvidas quatro imagens de mquinas virtuais para a plataforma de virtualizao KVM, no qual foi instalado o aplicativo UNIFOR Online em cada uma dessas imagens. O estudo de caso foi aplicado em dias diferentes, em relao aos testes realizados sobre a Arquitetura Uniforme (AU) e Arquitetura No Uniforme (ANU), produzindo resultados de taxa de erro divergentes entre as duas arquiteturas. Essa divergncia ocorreu devido sobrecarga do banco de teste no dia da realizao do cenrio de teste sobre ANU. Pode-se concluir que o desempenho do aplicativo UNIFOR Online fortemente dependente do desempenho do banco de dados. Se o banco de dados ou a mquina que hospeda o banco de dados estiver sobre forte carga de trabalho, o servidor de aplicao, aonde se encontra o UNIFOR Online, tende a perder as requisies realizadas pelos clientes.

51

Com a execuo dos testes sobre o conjunto ANU, foi observado atravs do monitor de recursos do OpenNebula, que as instncias do tipo small demoravam mais tempo para terminar o processamento das suas requisies, que instncias do tipo medium e large. Isso pode ser um fator limitante de desempenho, principalmente para aqueles conjuntos que possuem na sua composio muitas instncias do tipo small, como ANU 05 e ANU 06. Para trabalhos futuros, pretende-se continuar com o uso desse ambiente computacional, fazendo um estudo estendido para a criao de uma ferramenta para efetuar a automao da elasticidade em computao em nuvem, bem como desenvolver uma verso dessa ferramenta para funcionar em ambientes de nuvens de infraestrutura pblicas.

52

REFERNCIAS BIBLIOGRFICAS

ARMBRUST, M. et al. Above the Clouds: A Berkeley View of Cloud Computing. Relatrio Tcnico nmero EECS-2009-28. University of California, Berkeley, 2009. Cloud Computing Synopsis and Recommendations. NIST Special Pblication 800-146. Disponvel em: <http://csrc.nist.gov/pblications/drafts/800-146/Draft-NIST-SP800-146.pdf> FOSTER, I. et al. Cloud Computing and Grid Computing 360-Degree Compared. IEEE Grid Computing Environments Workshop, GCE08, Austin, Texas, United States, 2008. GALN, F.; SAMPAIO, A. et al. Service Specification in Cloud Environments Based on Extensions to Open Standards. In Proc of the Fourth International Conference on COMmunication System softWAre and MiddlewaRE (COMSWARE09), Dublin, Ireland, 2009. KUPERBERG, M. et al. Defining and Quantifying Elasticity of Resources in Cloud Computing and Scalable Platforms. Karlsruhe Reports in Informatics. Alemanha, BadenWrttemberg, 2011. LEAVITT, N. Is Cloud Computing Really Ready for Prime Time? IEEE Computer, Volume: 42 Numero: 1, pginas 15-20, Janeiro 2009. MATHER, T.; KUMARASWAMY, S; LATIF, S. Cloud Security and Privacy. OReilly, 2009.

53

MORENO-VOZMEDIANO, R. et al. Elastic management of cluster-based services in the cloud. In Proc. Of the 1st Workshop on Automated Control for Datacenters and Clouds, ACDC09, Barcelona, Espanha, 2009. OpenNebula About the OpenNebula Technology. Disponvel em:

http://opennebula.org/about:technology. Acesso em: 12 nov. 2011. REESE, George. Cloud Application Architectures. OReilly, 2009. RODERO-MERINO, L. et al. From infrastructure delivery to service management in clouds. Future Generation Computer Systems, volume 26, pginas 1226-1240, Maro 2010. SAMPAIO, A; MENDONA, N. Uni4Cloud: An Approach based on Open Standards for Deployment and Management of Multi-cloud Applications. Aceito em ICSE 2011 Software Engineering For Cloud Computing Workshop, Honolulu, Hawaii, 2011. SUN MICROSYSTEMS, Introduction to Cloud Computing Architecture White Paper, 1st Edition. Estados Unidos, Califrnia, 2009. VAQUERO, L. M.; RODERO-MERINO, L.; BUYYA R. Dynamically Scaling Applications in the Cloud. ACM SIGCOMM Computer Communication Review, volume 41, pginas 4552, Janeiro 2011. ZHANG, Q.; CHENG, L.; BOUTABA R. Cloud computing: state-of-the-art and research challenges. Journal of Internet and Services Applications, Volume 1, pg. 7-18, 2010. Zyngas Z Cloud Scale Fast or Fail By Merging Private And Public Clouds. Disponvel em: <http://highscalability.com/blog/2011/5/19/zyngas- z-cloud-scale- fast-or- fail- fast-by- mergingprivate-an.html>. Acesso em: 26 mai. 2011.