aCCounts: Uma arquitetura orientada a serviços para flexibilizar a tarifação em nuvens de infraestrutura

May 28, 2017 | Autor: Nayane Ponte | Categoria: Pricing, Computação Em Núvem
Share Embed


Descrição do Produto

aCCounts: Uma arquitetura orientada a servic¸os para flexibilizar a tarifac¸a˜ o em nuvens de infraestrutura Nayane Ponte∗ , Fernando Trinta∗ , Ricardo Viana∗ , Rossana Andrade∗ , Vin´ıcius Garcia† & Rodrigo Assad‡ ∗ Grupo

de Redes de Redes de Computadores, Engenharia de Software e Sistemas Universidade Federal do Cear´a, Fortaleza - CE Email: {nayaneviana, fernandotrinta, ricardoviana, rossana}@great.ufc.br † Centro de Inform´atica – Universidade Federal de Pernambuco, Recife - PE Email: [email protected] ‡ USTO.RE – Recife, PE Email: [email protected]

Abstract—Cloud Computing is a recent paradigm where different IT resources such as applications or hardware are quickly provisioned to customers through a pay per use model. Substantial research has already been conducted concerning pricing services in cloud computing, but they lack on flexibility to establish how services are accounted. These services seem also very dependent on specific cloud infrastructures. This paper proposes an architecture for charging cloud services decoupled from specific providers. This service is complemented by a domain specific language that allows the creation of flexible pricing policies. Such policies aims at supporting cloud billing requirements collected from a survey, allowing the construction of rules that meet different customer profiles. Based on this architecture, a prototype has been implemented and tested to validate our proposal in two different cloud infrastructures. These experiments aims at testing (i) the correctness of the charging flow between two components (server and agent) and (ii) the invoice calculation.

I.

˜ I NTRODUC¸ AO

A computac¸a˜ o em nuvem (do inglˆes, Cloud Computing) e´ um tema em grande evidˆencia tanto na ind´ustria quanto na academia. Segundo Vaquero et al [1], o termo computac¸a˜ o em nuvem refere-se a um conjunto de recursos virtuais de f´acil uso e acesso, que podem ser dinamicamente reconfigurados para se adequarem a uma carga de trabalho vari´avel, permitindo uma otimizac¸a˜ o no uso de tais recursos. Em geral, estes recursos s˜ao provisionados aos seus usu´arios como servic¸os. A literatura sobre computac¸a˜ o em nuvem apresenta trˆes modelos de entrega de servic¸os que podem ser vistos como sobreposic¸o˜ es em diferentes n´ıveis da pilha de uma infraestrutura de TI. No n´ıvel mais alto est˜ao as aplicac¸o˜ es, ou Software como Servic¸o (SaaS - do inglˆes, Software as a Service), nas quais os clientes podem utilizar sistemas de software com fins espec´ıficos, e que s˜ao acessados, em geral, a partir de um navegador Web. No n´ıvel intermedi´ario est´a a Plataforma como Servic¸o (PaaS - do inglˆes, Platform as a Service), que oferece tanto um ambiente de desenvolvimento quanto execuc¸a˜ o de aplicac¸o˜ es, incluindo frameworks, ferramentas de desenvolvimento e testes de aplicac¸o˜ es para nuvens espec´ıficas. Nestes dois n´ıveis, o usu´ario da nuvem n˜ao controla ou administra a infraestrutura subjacente, como rede, servidores, sistema operacional. No n´ıvel mais baixo, a Infraestrutura como Servic¸o (IaaS, do inglˆes Infrastructure as a Service) oferece m´aquinas

virtualizadas com sistemas operacionais pr´oprios, onde clientes podem instalar e configurar aplicac¸o˜ es de acordo com seus interesses. Neste u´ ltimo n´ıvel, o cliente da nuvem tem controle sobre as configurac¸o˜ es das m´aquinas virtuais, por´em n˜ao sobre a infraestrutura da nuvem. Independente do modelo utilizado, recursos em computac¸a˜ o em nuvem s˜ao tipicamente explorados por um modelo de pagamento por uso (do inglˆes, pay-as-you-go), com garantias oferecidas pelo provedor do servic¸o atrav´es de acordos de garantias de servic¸o (do inglˆes, Service Level Agreements). Em consequˆencia, a tarifac¸a˜ o de servic¸os e´ apontada como uma caracter´ıstica chave para computac¸a˜ o em nuvem[2], oferecendo desafios interessantes de pesquisa a serem estudados. Segundo Lucr´edio e Silva [3], ferramentas e mecanismos que facilitem o monitoramento e tarifac¸a˜ o de recursos, auxiliando as func¸o˜ es administrativas de gerenciamento da infraestrutura da nuvem s˜ao imprescind´ıveis para o sucesso da computac¸a˜ o em nuvem. Este trabalho aborda o tema de oferta de servic¸os em nuvem ao apresentar uma arquitetura, baseada em um modelo de referˆencia [4], para um servic¸o de tarifac¸a˜ o chamado aCCountS (a Cloud aCcounting Service), voltado para nuvens de infraestrutura. Nesse servic¸o, o administrador pode definir pol´ıticas de tarifac¸a˜ o de seus recursos de modo r´apido e simplificado, por meio de uma DSL - Linguagem de dom´ınio espec´ıfico (do inglˆes, Domain Specific Language), intitulada aCCountS-DSL. Esta proposta tem como objetivo principal definir uma soluc¸a˜ o que melhore a flexibilidade de como os recursos de um provedor de IaaS podem ser precificados e tarifados. Para alcanc¸ar tal objetivo, a linguagem aCCountSDSL foi especificada com objetivo de atender diversas quest˜oes em aberto no aˆ mbito da contabilizac¸a˜ o em nuvem, como a definic¸a˜ o de pol´ıticas de cobranc¸a flex´ıveis, de f´acil de manutenc¸a˜ o e que atendam a diferentes objetivos de cobranc¸a (lucro, bem estar social ou prec¸o justo). Por meio dos artigos encontrados em nossa revis˜ao liter´aria, v´arios trabalhos citam diferentes crit´erios (consumo m´edio de CPU e mem´oria, storage, dentre outros) como elementos interessantes para compor o prec¸o final do aluguel de m´aquinas virtuais em nuvens. Estes elementos podem ainda tornar a cobranc¸a mais flex´ıvel e compreens´ıvel (as regras de tarifac¸a˜ o) aos clientes de servic¸os de nuvem. Por meio da aCCountS-

DSL e´ poss´ıvel criar regras para tarifar diferentes recursos ou requisitos propostos. Ela evita a reprogramac¸a˜ o do componente de contabilizac¸a˜ o da nuvem, alterando apenas suas regras, que s˜ao atualizadas dinamicamente pelo sistema. Para validac¸a˜ o da proposta, um prot´otipo do aCCountS foi implementado e testado em duas infraestruturas de nuvens distintas. Estes experimentos objetivaram testar a corretude do (i) fluxo de tarifac¸a˜ o entre os dois componentes (agente e servidor) e do (ii) c´alculo da fatura. E´ v´alido ressaltar que o projeto de uma soluc¸a˜ o de tarifac¸a˜ o envolve muitos aspectos al´em da flexibilidade, como por exemplo, seguranc¸a e escalabilidade. Por´em, no contexto deste trabalho, estes aspectos n˜ao s˜ao abordados. Este artigo est´a organizado em seis sec¸o˜ es. A partir desta introduc¸a˜ o, a segunda sec¸a˜ o aponta trabalhos relacionados a` proposta aCCountS. A terceira sec¸a˜ o apresenta uma vis˜ao geral sobre o funcionamento do aCCountS. Em seguida, a sec¸a˜ o 4 apresenta sua arquitetura destacando seus componentes e a linguagem aCCountS-DSL. A sec¸a˜ o cinco descreve a avaliac¸a˜ o experimental e a an´alise da nossa proposta. Por fim, a sexta sec¸a˜ o apresenta conclus˜oes e trabalhos futuros. II.

T RABALHOS R ELACIONADOS

A tarifac¸a˜ o em nuvem ainda e´ um campo recente de pesquisa. Por´em, durante a fase inicial deste estudo foram realizadas pesquisas nas quais foram encontrados artigos e trabalhos que j´a exploraram o tema. Nesta sec¸a˜ o s˜ao apresentados alguns destes trabalhos que contribuem para a proposta aCCountS. O trabalho de Silva et al [5] teve um papel importante neste levantamento inicial ao apresentar um estudo de mapeamento sobre a tarifac¸a˜ o em computac¸a˜ o em nuvem. Neste mapeamento, um trabalho em destaque e´ a proposta de Ruiz-Agundez et al [4] para um processo de tarifac¸a˜ o para recursos computacionais. Este trabalho e´ apontado como a u´ nica referˆencia para uma taxonomia completa de um processo de contabilizac¸a˜ o e tarifac¸a˜ o de recursos, conforme descrito na Figura 1. O fluxo de tarifac¸a˜ o proposto por Ruiz-Agundez et al [4] e´ composto de oito tarefas, nas quais o resultado de uma serve como entrada para uma tarefa seguinte. A primeira tarefa e´ a medic¸a˜ o e sua func¸a˜ o e´ monitorar o uso de recursos na nuvem. Estes recursos podem ser o consumo de CPU ou mem´oria de uma determinada m´aquina virtual. A segunda tarefa e´ a mediac¸a˜ o, que refina os dados recebidos da tarefa anterior, transformando-os em dados mais f´aceis de serem manipulados pelas pr´oximas etapas. Ap´os a mediac¸a˜ o, a tarefa de contabilidade tem por func¸o˜ es a filtragem, a coleta e a agregac¸a˜ o das informac¸o˜ es sobre o uso de recursos por um determinado cliente. Como resultado de sua execuc¸a˜ o, registros de sess˜ao s˜ao enviados para a cobranc¸a, que realiza as tarefas relacionadas a gerac¸a˜ o dos registros de cobranc¸a para um cliente espec´ıfico. A tarefa de precificac¸a˜ o e´ respons´avel por definir as operac¸o˜ es que ser˜ao realizadas no c´alculo da tarifac¸a˜ o. A tarefa cobranc¸a realiza o c´alculo da cobranc¸a a partir dos dados medidos pela nuvem (contabilidade) e dos valores dos recursos monitorados (precificac¸a˜ o). Em seguida, tarefa de faturamento recebe os registros de cobranc¸a realizados durante um per´ıodo de tempo, para ent˜ao calcular a fatura completa. Caso o faturamento calculado seja de um cliente de

Fig. 1.

Fluxo de tarifac¸a˜ o, adaptado de Ruiz-Agundez et al [4]

outra m´aquina virtual ou nuvem, esses dados s˜ao repassados para a tarefa roaming, cuja func¸a˜ o e´ envi´a-lo para a m´aquina virtual ou nuvem onde o cliente possua cadastro. Por fim, a fatura tamb´em e´ enviada a` tarefa de compensac¸a˜ o financeira, que realiza o cumprimento do pagamento da fatura. Outra preocupac¸a˜ o do estudo proposto pelos autores e´ a forma que a pol´ıtica de tarifac¸a˜ o e´ implementada. Segundo Ruiz-Agundez et al [4], cada provedora de nuvem desenvolve seu sistema de contabilizac¸a˜ o pr´oprio e o codifica diretamente na infraestrutura da nuvem, dificultando manutenc¸o˜ es na pol´ıtica de neg´ocios. Na proposta de Ruiz-Agundez et al [4], diferentes requisitos de nuvem foram levados em conta, com objetivo de tornar a tarifac¸a˜ o flex´ıvel, permitindo a alterac¸a˜ o das pol´ıticas de forma f´acil. Por´em, para validar seu modelo, o fluxo descrito na Figura 1 foi implementado em um servic¸o de tarifac¸a˜ o comercial, chamado de JBilling1 , o que impede que maiores detalhes a respeito da soluc¸a˜ o possam ser estudados. Trabalhos interessantes tamb´em podem ser obtidos no campo da computac¸a˜ o em grade, e que podem ser aproveitados para a computac¸a˜ o em nuvem. Caracas e Altmann [6] prop˜oem tarifar os servic¸os de uma grade levando em considerac¸a˜ o fatores como a quantidade de recursos, o tempo no qual tais recursos foram utilizados, a qualidade do servic¸o e o perfil do usu´ario. Al´em disso, e´ proposta uma definic¸a˜ o dinˆamica de prec¸os, na qual a tarifac¸a˜ o utiliza componentes da infraestrutura da grade para disponibilizar dados para o faturamento. J´a Narayan [7] prop˜oe que os esquemas de tarifac¸a˜ o deveriam levar em considerac¸a˜ o n˜ao apenas os perfis de hardware utilizados e seu tempo de uso, mas o pr´oprio uso dos recursos, 1 http://www.jbilling.com/

como mem´oria, CPU e disco. Al´em de estudos acadˆemicos, foi tamb´em verificado como a ind´ustria utiliza a tarifac¸a˜ o em servic¸os de computac¸a˜ o em nuvem. A utilizac¸a˜ o desses servic¸os de tarifac¸a˜ o dispon´ıveis no mercado, tais como JBilling e Cloud Billing2 , s˜ao baseadas em BRMS - Business Rule Management System (Sistemas de regras de neg´ocios). Apesar desse tipo de sistema proporcionar uma facilidade na definic¸a˜ o das regras de neg´ocio por usu´arios que n˜ao tem conhecimentos em programac¸a˜ o, segundo Hartmann Software Group [8], (i) os BRMS n˜ao s˜ao otimizados para tarefas computacionais que requerem alto processamento, (ii) n˜ao s˜ao ambientes ideais para escrever algoritmos complexos (diminuindo a eficiˆencia do mecanismo de regras e tornando dif´ıcil para os usu´arios definirem formas mais complexas) e (iii) perturbac¸o˜ es em seus modelos de objeto (ou regras) podem ter implicac¸o˜ es em todo o sistema (dado que as regras s˜ao definidas por outras regras ou modelos de objetos, criando um caminho de dados para realizar a inferˆencia). Outra quest˜ao levantada nos artigos estudados e´ quanto ao objetivo da pol´ıtica de tarifac¸a˜ o. Segundo Caracas [6], uma pol´ıtica de tarifac¸a˜ o de uma provedora de nuvem busca alcanc¸ar tipos diferentes de finalidades, tais como maximizar os lucros, maximizar o bem estar social ou definir um esquema de prec¸o justo. A forma como os servic¸os de nuvem s˜ao cobrados no mercado n˜ao parece justa quando dois clientes que requisitam instˆancias iguais na nuvem pagam o mesmo prec¸o, mesmo o primeiro utilizando 90% dos recursos da m´aquina virtual instanciada, enquanto o segundo usa apenas 10% de uma instˆancia semelhante. Tamb´em n˜ao parece pensar no bem estar social, quando n˜ao se preocupa com o grande gasto de energia nos centros de dados, n˜ao promovendo incentivos a clientes que aceitariam medidas com prop´osito de diminuir a demanda por energia [6]. Tomando por base os trabalhos encontrados relacionados a` tarifac¸a˜ o, o aCCountS utiliza partes de cada um deles. No caso do Ruiz-Agundez et al [4], seu processo de tarifac¸a˜ o e´ utilizado, por´em sem a tarefa de roaming. O aCCountS define uma linguagem de dom´ınio espec´ıfico para definic¸a˜ o de pol´ıticas com a possibilidade de definir um conjunto de recursos monitores. Nestas pol´ıticas, os crit´erios propostos por Caracas e Altmann [6] podem ser explorados. Por fim, as pol´ıticas definidas na linguagem aCCountS-DSL tamb´em podem utilizar a proposta de Narayan [7], contabilizando a quantidade de recursos consumidos, como por exemplo, dando desconto a usu´ario que consome apenas 50% de seus recursos na nuvem. III.

aCCountS - Cloud aCCOUNTing Service

Com base nos estudos levantados, este trabalho prop˜oe uma nova forma de contabilizac¸a˜ o para servic¸os em nuvem. Essa proposta constitui-se de dois elementos. O primeiro e´ um servic¸o de tarifac¸a˜ o em nuvem, que possui seu fluxo de execuc¸a˜ o na proposta de Ruiz-Agundez et al, explicada anteriormente. O servic¸o e´ formado por dois componentes, o agente de monitoramento e o componente de tarifac¸a˜ o. O agente monitora os recursos das m´aquinas virtuais e o componente interpreta regras de tarifac¸a˜ o definidas pela provedora de nuvem (administrador), contabiliza a utilizac¸a˜ o destes 2 http://www.ibm.com/developerworks/cloud/library/cl-devcloudmodule/

recursos e gera uma conta de tarifac¸a˜ o para o cliente. O segundo elemento e´ uma linguagem de dom´ınio espec´ıfico, chamada aCCountS-DSL, que permite a administradores de nuvem definirem regras de tarifac¸a˜ o para recursos de sua infraestrutura no servic¸o. A Figura 2 mostra uma vis˜ao geral sobre o aCCountS.

Fig. 2.

Vis˜ao Geral da Proposta

Em linhas gerais, pode-se separar a utilizac¸a˜ o do servic¸o em duas etapas. Na etapa inicial e´ feita sua configurac¸a˜ o. Nela, o administrador da nuvem precisa definir os parˆametros de tarifac¸a˜ o, ou seja, quais ser˜ao os recursos monitorados nas m´aquinas virtuais de sua nuvem, e que ser˜ao utilizados para composic¸a˜ o das regras de tarifac¸a˜ o. Em geral, estes recursos incluem uso de CPU, mem´oria, disco, tempo de uso, transac¸o˜ es em bancos de dados, servic¸os e software utilizados, dentre outros. Ap´os esta definic¸a˜ o, faz-se necess´ario estabelecer valores (parˆametros de precificac¸a˜ o) para os recursos que ser˜ao monitorados. Na proposta do aCCountS, a precificac¸a˜ o e´ fortemente atrelada ao conceito de perfil de uma m´aquina virtual. Este perfil refere-se a` s poss´ıveis configurac¸o˜ es das m´aquinas virtuais que podem ser instanciadas na nuvem, de forma semelhante ao que acontece em infraestruturas de nuvem conhecidas, como Amazon EC2 ou GoGrid. Por exemplo, na Amazon AWS, o usu´ario pode escolher entre instˆancias do tipo Micro, Pequena, M´edia, Grande e ExtraGrande[9]. Cada uma destas instˆancias tem valores diferentes para seu uso. Com estes parˆametros definidos, o administrador pode criar as pol´ıticas de tarifac¸a˜ o de sua nuvem utilizando a aCCountSDSL. Neste caso, as pol´ıticas definem as diferentes pr´aticas em relac¸a˜ o a cobranc¸a pelo uso de recursos de suas m´aquinas virtuais instanciadas. Estas pol´ıticas podem incluir uma tarifac¸a˜ o apenas pelo tempo de uso de uma m´aquina virtual, ou podem agregar taxas em relac¸a˜ o ao uso dos recursos de rede, m´edia de consumo de mem´oria, quantidade de transac¸o˜ es no banco de dados, al´em de descontos por economia de energia, SLA ou perfil do cliente. Almeja-se utilizar os diferentes requisitos de contabilizac¸a˜ o para criar uma pol´ıtica flex´ıvel. A segunda etapa diz respeito a` execuc¸a˜ o do servic¸o. Para isto, em cada m´aquina virtual, um agente e´ respons´avel por coletar informac¸o˜ es dos parˆametros de tarifac¸a˜ o e repass´a-las a um reposit´orio. De posse das informac¸o˜ es sobre consumo de recursos das m´aquinas virtuais e de como os recursos devem ser tarifados, o tarifador pode ent˜ao gerar uma conta de consumo para clientes da nuvem. Para melhor especificar cada uma destas etapas, a pr´oxima sec¸a˜ o aborda em mais detalhes (i) a arquitetura do servic¸o

Fig. 3.

Diagrama de componentes UML com os principais elementos de aCCountS

proposto e (ii) a linguagem de dom´ınio espec´ıfico, aCCountSDSL IV.

O iParameters faz uma chamada ao aCCountS-Service, solicitando quais parˆametros dever˜ao ser monitorados. Esses parˆametros j´a foram configurados com os recursos que ser˜ao medidos e a forma de med´ı-los. Para exemplificar esta configurac¸a˜ o, o C´odigo 1 mostra vari´aveis que foram cadastradas para medir uso de CPU, mem´oria e disco, com a respectiva forma de capturar seus valores para o sistema operacional Linux na Amazon EC2.

A RQUITETURA DO aCCountS

A arquitetura do aCCountS e´ representada na Figura 3, por meio de um diagrama de componentes UML. Nesta figura, os elementos marcados com o estere´otipo Entity representam abstrac¸o˜ es que denotam dados manipulados na proposta aCCountS. Os demais componentes da arquitetura assumem o papel de gerenciadores destes recursos e exercem papel de processamento das etapas do fluxo de tarifac¸a˜ o. A arquitetura aCCountS possui dois macro-componentes: (i) o aCCountSAgent e o (ii) aCCountS-Service. O primeiro representa o agente de coleta de informac¸o˜ es, e que deve estar presente em cada m´aquina virtual em execuc¸a˜ o na nuvem. O segundo representa um servic¸o que recebe os dados monitorados, e que atrav´es da configurac¸a˜ o de seus sub-componentes, consegue gerar a tarifac¸a˜ o das m´aquinas virtuais associadas a um determinado cliente. A divis˜ao do aCCountS em macro-componentes foi motivada pela ideia de um servic¸o de tarifac¸a˜ o em nuvem desacoplado da infraestrutura da mesma. Com isto, objetiva-se a concepc¸a˜ o de um componente reutiliz´avel, no caso o servic¸o, que pode ser utilizado para realizar o processo de tarifac¸a˜ o para diferentes nuvens de infraestrutura. A comunicac¸a˜ o entre o aCCountS-Agent e o aCCountSService e´ realizado por meio de troca de mensagens no formato JSON3 . Como ilustrado na Figura 3-(b), o aCCountSService fornece uma API para comunicac¸a˜ o com o agente. A interface iParameters serve para que o aCCountS-Agent obtenha do servic¸o, quais s˜ao os recursos (parˆametros) a serem monitorados e como estes devem ser obtidos da m´aquina virtual onde o agente est´a sendo executado. J´a a interface iResources permite que o agente envie os registros de medic¸a˜ o, a partir dos recursos monitorados. Dessa maneira, qualquer empresa de nuvem pode criar seu pr´oprio agente para tarifar seus servic¸os, desde que mantendo a compatibilidade com a API fornecida. 3 http://www.json.org/

C´odigo 1. 1 2 3

Definic¸a˜ o dos recursos a serem medidos - Amazon EC2

{ "cpu": uptime | awk -F’: ’ ’{print $2}’ | awk -F’, ’ ’{ print $1}’, "memoria": free -m|grep Mem|awk ’{printf("%f", $3/$2)}’, "armazenamento": df -k ’/dev/disk/by-label/cloudimg-rootfs ’ | grep udev | awk ’{printf("% f", $3/$4)}’ }

O iResources periodicamente envia ao aCCountS-Service as informac¸o˜ es de uso da m´aquina virtual para o c´alculo da fatura. O C´odigo 2 mostra um exemplo de um arquivo JSON enviado pelo aCCountS-Agent via iResources. Nas pr´oximas duas sub-sec¸o˜ es ser˜ao descritos em mais detalhes como os subcomponentes aCCountS-Agent e aCCountS-Service operam para o estabelecimento do fluxo de tarifac¸a˜ o. C´odigo 2. 1

Exemplo de um registro de medic¸a˜ o

{ "cpu": 0.06068, "memoria": 0.54445, "armazenamento": 0.05128 }

A. O Agente - aCCountS-Agent O aCCountS-Agent e´ formado pelos sub-componentes AgentReceptorManager, o MeteringVM, MediatorVM e pelo AgentSendManager, como modelado pelo diagrama de componentes mostrado na Figura 3 - (a). Cada sub-componente do aCCountS-Agent realiza um passo para atender a funcionalidade de monitoramento de recursos de uma m´aquina virtual. Estes passos s˜ao (i) identificar os recursos que devem ser monitorados, (ii) realizar a medic¸a˜ o e (iii) a mediac¸a˜ o destes recursos, e por fim, (iv) enviar as informac¸o˜ es de consumo para o aCCountS-Service. Na arquitetura do aCCountS-Agent, o AgentReceptorManager e´ respons´avel por buscar no aCCountS-Service os

parˆametros (API iParameters), interpret´a-los e envi´a-los ao sub-componente MeteringVM. Um AgentReceptorManager de uma m´aquina virtual est´a associado a uma m´aquina no aCCountS-Service por meio de um identificador u´ nico (id). Na requisic¸a˜ o dos parˆametros, o agente utiliza este identificador, permitindo ao aCCountS-Service reconhecer a pol´ıtica de tarifac¸a˜ o da m´aquina virtual e quais recursos que devem ser monitorados, para ent˜ao, fornecˆe-los de forma correta ao agente, de acordo com seu sistema operacional. Cada parˆametro recebido pelo AgentReceptorManager e´ um arquivo JSON com uma lista dos recursos e seus respectivos comandos para serem monitorados a partir do Sistema Operacional implantado na m´aquina virtual. Dado que os (i) parˆametros e seus comandos de execuc¸a˜ o, (ii) a pol´ıtica definida para tarifac¸a˜ o da m´aquina virtual e (iii) seu perfil de precificac¸a˜ o foram definidos na primeira parte do processo, a etapa de configurac¸a˜ o do aCCountS est´a completada. Por meio dos comandos passados pelo AgentReceptorManager, o MeteringVM mede a utilizac¸a˜ o de cada recurso na m´aquina virtual em uma certa frequˆencia predeterminada e envia esses registros para o componente MediatorVM que os intermedia. O MediatorVM recebe os dados medidos, calcula a m´edia de utilizac¸a˜ o dos recursos e a cada hora, gera um registro de medic¸a˜ o. Esses registros s˜ao conduzidos para o AgentSendManager, que os expede, uma vez ao dia, para o aCCountS-Service (API iResources). Os tempos de medic¸a˜ o e de envio dos registros ao servic¸o podem ser configurados pela administrador da infraestrutura de nuvem, mas a configurac¸a˜ o padr˜ao no MeteringVM indica que os dados s˜ao monitorados a cada minuto, enquanto o MediatorVM realiza suas func¸o˜ es em intervalos de uma hora. Esta decis˜ao pretende n˜ao sobrecarregar a rede com informac¸o˜ es de medic¸a˜ o a cada minuto no tr´afego de dados entre agente e servic¸o, nem o pr´oprio aCCountS-Service. O aCCountS-Service com posse das informac¸o˜ es de consumo de uma m´aquina virtual inicia seu processo de tarifac¸a˜ o por meio dos seus sub-componentes, como especificado na pr´oxima subsec¸a˜ o. B. O Servic¸o - aCCountS-Service Como foi declarado, o aCCountS-Service foi idealizado para ser um servic¸o de tarifac¸a˜ o para qualquer provedora de nuvem. Para isto, e´ necess´ario instalar um agente nas m´aquinas virtuais em execuc¸a˜ o, de tal modo que estes agentes busquem os parˆametros (recursos e comandos para serem monitorados) no aCCountS-Service (interface iParameters), para em seguida monitorar o uso da m´aquina virtual e enviar ao servic¸o os registros de mediac¸a˜ o (m´edia de uso dos recursos) ao servic¸o (interface iResources). A tarifac¸a˜ o de cada m´aquina virtual e´ processada por meio dos sub-componentes do aCCountS-Service, que recebem os registros de medic¸a˜ o e geram uma fatura mensal para o cliente. Esses sub-componentes s˜ao o ResourcesManager, o AccountingManager, o PriceManager, o ProfileManager, o BillingManager e o ClientManager. O PriceManager e´ ainda subdivido em outros trˆes componentes, a saber: PolicyManager, DSL-Compiler e ChargeManager. A arquitetura do aCCountS-Service e´ ilustrada na Figura 3-(c) por meio de um diagrama de componentes UML.

No aCCountS-Service, o ResourcesManager tem a func¸a˜ o de enviar os parˆametros para o agente, quando solicitado. Duas entidades s˜ao manipuladas por este componente: o Resources e o CommandsResources. A primeira representa os recursos a serem monitorados, enquanto a segunda, os comandos que os agentes devem executar para medir tais recursos. Esta configurac¸a˜ o deve ser feita pelo administrador da provedora da nuvem, que cadastra todos os recursos que poder˜ao ser monitorados por ela e os seus respectivos comandos. Em nosso prot´otipo, esta configurac¸a˜ o e´ feita por meio de uma interface Web. O ResourcesManager ao ser consultado pelo agente, recebe o identificador da m´aquina virtual. Por meio deste identificador, sua pol´ıtica de tarifac¸a˜ o e´ recuperada. Com isto, o ResourcesManager verifica na pol´ıtica quais recursos precisam ser medidos e os envia por meio de parˆametros (recursos e comandos) ao agente. J´a o AccountingManager tem a func¸a˜ o de receber os registros de medic¸a˜ o do agente e ativar o componente PriceManager para contabilizar os registros recebidos. Este componente e´ respons´avel por gerar a func¸a˜ o de precificac¸a˜ o para contabilizar os registros de medic¸a˜ o, al´em de calcular o custo do servic¸o e gerar as cobranc¸as. Estas tarefas s˜ao distribu´ıdas entre seus sub-componentes: PolicyManager, DSL-Compiler e ChargeManager. O PolicyManager gerencia a criac¸a˜ o das pol´ıticas de tarifac¸a˜ o. Essas pol´ıticas s˜ao definidas atrav´es da DSL proposta nesse trabalho que ser´a descrita com mais detalhes na sub-sec¸a˜ o IV-C. O DSL-Compiler compila a pol´ıtica de tarifac¸a˜ o definida e gera uma func¸a˜ o de precificac¸a˜ o, enquanto o ChargeManager utiliza a func¸a˜ o definida para calcular os registros de cobranc¸a por meio dos recursos monitorados no agente e dos prec¸os dos recursos (requisitados do componente ProfileManager). O componente ProfileManager e´ respons´avel por gerenciar o perfil das m´aquinas virtuais do agente. Ele manipula duas entidades: o Resources que representa cada recurso, e o Price que representa os prec¸os desses recursos. Estes componentes s˜ao cadastrados pelo administrador da provedora de nuvem durante o processo de configurac¸a˜ o do servic¸o. No ProfileManager, al´em dos recursos e seus prec¸os, deve-se cadastrar os perfis dispon´ıveis na infraestrutura da nuvem, definindo a quantidade de mem´oria, armazenamento em disco e tipo de processador das m´aquinas virtuais que podem ser instanciadas. Os registros de cobranc¸a calculados pelo ChargeManager s˜ao enviados para o componente BillingManager, cuja principal func¸a˜ o e´ som´a-los para gerac¸a˜ o da fatura que ser´a enviada para o ClientManager ao final de cada mˆes, caso o modelo de tarifac¸a˜ o seja p´os-pago. Caso o modelo da pol´ıtica de tarifac¸a˜ o seja pr´e-pago, uma mensagem e´ enviada para a provedora da nuvem no momento em que o total de cr´editos do cliente for esgotado. O valor do cr´edito e´ medido pelo agente e enviado para o AccountingManager via iResources. Com essa informac¸a˜ o a provedora da infraestrutura de nuvem pode tomar providˆencias pela continuidade ou n˜ao da oferta de servic¸os ao cliente cujo cr´edito se esgotou. C. A DSL de tarifac¸a˜ o - aCCountS-DSL No contexto deste trabalho, uma pol´ıtica de tarifac¸a˜ o e´ definida como um conjunto de regras que estabelece a forma

como recursos das m´aquinas virtuais de um cliente s˜ao tarifados. A aCCountS-DSL e´ uma linguagem de dom´ınio espec´ıfico textual para criac¸a˜ o de pol´ıticas de tarifac¸a˜ o em nuvens de IaaS dentro da proposta aCCountS. O projeto da aCCountS-DSL foi elaborado a partir de requisitos obtidos dos trabalhos relacionados previamente descritos, bem como a partir de exemplos da ind´ustria, com destaque para a Amazon EC2, uma vez que esta se trata da principal fornecedora de servic¸os de infraestrutura em nuvem do mundo, segundo Marten Mickos4 . Para ilustrar esta influˆencia, na etapa de configurac¸a˜ o (primeira parte do processo de tarifac¸a˜ o), o perfil da m´aquina e´ definido no aCCountS-Service pelo administrador, que precifica os recursos que ser˜ao contabilizados. Um conjunto de requisitos de tarifac¸a˜ o determina o valor de um perfil, muito semelhante ao que ocorre na Amazon EC2, em que os diferentes requisitos definem as diferentes instˆancias e seus prec¸os. Por exemplo, uma instˆancia localizada na Virg´ınia, cuja pol´ıtica e´ sob-demanda e o perfil da m´aquina e´ small-instance custa $ 0.06 por hora de uso. Se sua pol´ıtica for reservada por um ano, custar´a $ 0.034 por hora de uso. Se o perfil da m´aquina modificar, passando para medium-instance, o custo do servic¸o passar´a a $ 0.12 por hora de uso. A aCCountS-DSL busca permitir que qualquer nuvem possa definir suas regras e criar sua pol´ıtica de tarifac¸a˜ o atrav´es de uma linguagem que atenda aos requisitos utilizados pela Amazon e aos requisitos apontados nos trabalhos relacionados apresentados na sec¸a˜ o II. Os requisitos utilizados pelo aCCountS s˜ao apresentados a seguir. 1.1 - Garantia de alocac¸a˜ o: Algumas pol´ıticas de tarifac¸a˜ o promovem maior garantia a` nuvem do que outras, impactando nos custos dos seus recursos. A Amazon[9] utiliza trˆes modelos e os mesmos s˜ao suportados pela linguagem e servic¸o propostos. S˜ao eles: (i) sob-demanda, que permite ao cliente pagar pela capacidade computacional utilizada por hora, sem nenhum compromisso de longo prazo, (ii) Reservado, que oferece a opc¸a˜ o de um pagamento u´ nico e acess´ıvel para cada instˆancia que o cliente deseja reservar e, em troca, um desconto significativo sobre a custo de utilizac¸a˜ o dos servic¸os para essa instˆancia, e (iii) Lance, que e´ concedido por meio de leil˜ao dos recursos subutilizados, sem uma garantia sobre o tempo de disponibilidade do servic¸o. Este requisito e´ definido no momento da configurac¸a˜ o do perfil, na qual os prec¸os dos recursos variam conforme seu requisito. 1.2 - Modelo de pagamento: Os modelos propostos pela Amazon atualmente s˜ao p´os-pagos. Entretanto, outros servic¸os de tecnologia aumentaram sua utilizac¸a˜ o atrav´es de planos pr´e-pagos, como a telefonia m´ovel e a Internet m´ovel [10]. Dessa maneira, a linguagem proposta reconhece dois modelos poss´ıveis de pagamento. O primeiro e´ o modelo pr´e-pago, no qual um cliente paga antes de utilizar os recursos, podendo limitar seu uso pelos cr´editos comprados. J´a o modelo p´ospago reflete o modo tradicional em que um cliente contrata um plano de utilizac¸a˜ o e paga ap´os o uso, em geral numa frequˆencia mensal. Estes modelos foram influenciados pela proposta de Elmroth [11] e pelos servic¸os de tecnologia citados anteriormente. O modelo de pagamento e´ suportado pela arquitetura pro4 www.livestream.com/gigaomtv/video?clipId=pla 7a8babfe-7b50-472ebbb8-1619d153ada4&utm source=lslibrary&utm medium=ui-thumb

posta, entretanto ainda n˜ao est´a completamente funcional no prot´otipo implementado. A aplicac¸a˜ o desse requisito acontece em quatro etapas, sendo que as trˆes primeiras ocorrem no momento de configurac¸a˜ o do servic¸o, enquanto a quarta ocorre durante a execuc¸a˜ o do mesmo. A primeira etapa acontece na configurac¸a˜ o dos parˆametros, em que o administrador define os recursos de modelo de pagamento e cr´edito, e os associa a um determinado cliente. A segunda etapa ocorre quando da criac¸a˜ o dos perfis das m´aquinas, e leva em considerac¸a˜ o o modelo da pol´ıtica. No caso, definem-se prec¸os maiores para perfis com modelo pr´e-pago. A terceira etapa permite ao administrador configurar os tempos de medic¸a˜ o e de envio de dados para o servic¸o. J´a na u´ ltima etapa, o agente faz medic¸o˜ es dos recursos de cr´edito e de tipo de modelo de pagamento. 1.3 - Forma de contabilizac¸a˜ o: Segundo alguns autores [12], [6], [11], [7], um servic¸o em nuvem consome diferentes recursos e em quantidades diferentes, sendo portanto justo pagar apenas pelos recursos consumidos, evitando que aqueles que utilizem pouco paguem o mesmo que outros que sobrecarregam o sistema. Desta forma, este requisito estabelece que um cliente possa ser tarifado por uso dos recursos (Ex: uso de 10% de CPU de uma m´aquina virtual em uma hora custa $ 0.003) ou por tempo de uso (1h de uso de uma m´aquina custa $ 0.3) ou ainda por uma opc¸a˜ o h´ıbrida definida pela provedora de nuvem. Esse requisito e´ suportado na definic¸a˜ o da pol´ıtica de tarifac¸a˜ o. 1.4 - Perfil de hardware: m´aquinas com diferentes capacidades de processamento e disponibilidade de armazenamento e mem´oria apresentam prec¸os diferentes. Por exemplo, na Amazon EC2, uma instˆancia Linux com perfil small (com disponibilidade de recursos pequena) custa $ 0.06 por hora, enquanto que o perfil medium aumenta seu valor para $ 0.12 por hora. Se o perfil escolhido for large, o custo aumenta para $ 0.24 por hora. Este requisito e´ suportado pela arquitetura por meio da configurac¸a˜ o dos perfis das m´aquinas. O administrador deve levar em considerac¸a˜ o o tipo de hardware para precificar os recursos do perfil. 1.5 - Utilit´arios: Na configurac¸a˜ o de uma m´aquina virtual para um cliente, recursos adicionais podem ser associados a` tarifac¸a˜ o. Por exemplo, clientes podem ser tarifados pelo uso de software propriet´ario (como o sistema operacional Microsoft Windows), por servic¸os disponibilizados pela provedora de nuvem (como elasticidade autom´atica) ou por uso de centro de dados localizados em regi˜oes estrat´egicas com maior disponibilidade ou recursos adicionais. Por exemplo, no centro de dados da Amazon EC2 localizado na Virg´ınia (EUA), uma instˆancia small utilizando o Linux custa $ 0.06 por hora, enquanto no centro de dados da Amazon situado em S˜ao Paulo, a mesma instˆancia custa $ 0.08 por hora. Em geral, software, servic¸os e datacenters requerem custos adicionais a` provedora de nuvem, sendo portanto, requisitos a serem considerados na definic¸a˜ o da pol´ıtica de tarifac¸a˜ o. 1.6 - Bem Estar social: Este conceito relaciona-se com a ideia de se promover descontos na fatura do cliente em determinadas situac¸o˜ es, como o uso de m´aquinas virtuais configuradas visando a economia de energia [13], grande quantidade de recursos utilizados por um cliente espec´ıfico [12], recursos da nuvem sub-utilizados [6] e ainda quest˜oes que atendam aos SLAs (multa a` s provedoras, quando houver

alguma violac¸a˜ o nesses acordos) [12]. Esses requisitos s˜ao definidos nas regras de cobranc¸a.

Para melhor ilustrar o uso da aCCountS-DSL, o C´odigo 4 apresenta a definic¸a˜ o de uma pol´ıtica, intitulada SobMedUsoPosPlus. Seu nome referencia alguns dos requisitos que ela atende, a saber: Sob-demanda(garantia de alocac¸a˜ o), Media(perfil de m´aquina), Uso(forma de contabilizac¸a˜ o), Pospago(modelo), Plus, por contabilizar quest˜oes a mais (requisitos Utilit´arios e de Bem estar social). Nela s˜ao definidas dez vari´aveis para auxiliar a definic¸a˜ o das regras: taxaCentralDados, memoria, cpu, armazenamento, transacaoBD, upload, descontoEnergia, descontoUsuario, desconto e custo.

A partir da definic¸a˜ o dos requisitos e de como e´ fornecido o suporte aos mesmos, a flexibilidade da tarifac¸a˜ o e´ alcanc¸ada pela combinac¸a˜ o das v´arias possibilidades de tarifac¸a˜ o em pol´ıticas que possam atender diferentes tipos de clientes (com necessidades, recursos e perspectivas diferentes) e atender a diferentes objetivos de cobranc¸a por parte das provedoras de nuvem (lucro, bem estar social e prec¸os justos).

O conjunto de requisitos apresentado serviu de base para a C´odigo 4. Pol´ıtica de tarifac¸a˜ o criada por meio da aCCountS-DSL definic¸a˜ o da linguagem aCCountS-DSL. Atrav´es dela podeSobMedUsoPosPlus { se definir diferentes conjuntos de regras para atender aos 12 Policy var { diferentes requisitos propostos. Eles podem ser combinados 3 taxaCentralDados, memoria, cpu, armazenamento; upload,transacaoBD, custo, descontoEnergia; entre si, criando uma sequˆencia de instruc¸o˜ es (regras) para 4 5 descontoUsuario, desconto; definir a pol´ıtica de tarifac¸a˜ o. De modo a ilustrar seus prin- 6 } rules{ cipais elementos, o C´odigo 3 apresenta a estrutura geral de 7 descontoEnergia = 0; uma pol´ıtica descrita usando a linguagem. Ressalta-se que seu 89 descontoUsuario = 0; objetivo maior e´ a flexibilidade na definic¸a˜ o das pol´ıticas de 10 taxaCentralDados = 0.14; tarifac¸a˜ o, de modo a utilizar diferentes recursos das m´aquinas 11 memoria = instance.memoria * $memoria; virtuais de uma nuvem de infraestrutura, que possam ser 12 13 cpu = instance.cpu * $cpu; medidos e precificados. 14 armazenamento = instance.armazenamento * $armazenamento; transacaoBD = instance.transacaoBD * $transacaoBD; upload = instance.upload * $upload;

15

C´odigo 3. 1 2 3 4 5 6 7 8 9 10 11

Definic¸a˜ o de uma pol´ıtica de tarifac¸a˜ o com a aCCountS-DSL

Policy nome_da_politica [extends outra_politica] { var { definicao das variaveis auxiliares para definir regras de negocio; } rules{ definicao de regras de negocio atraves de operacoes aritmeticas e logicas; } return valor_da_cobranc ¸a; }

16 17 19 20 21 22 23 24 25 26 27

custo = memoria + cpu + armazenamento + transacaoBD + upload + instance.software + instance.servico + taxaCentralDados; desconto = instance.sla + descontoEnergia + descontoUsuario; custo = custo - custo * desconto;

28

Os elementos que estruturam a pol´ıtica s˜ao definidos da 29 seguinte forma: O elemento policy representa o nome de uma 30 pol´ıtica espec´ıfica. Este elemento divide-se em duas sec¸o˜ es. 31 Na primeira sec¸a˜ o, especificada pela palavra-reservada var, 32 s˜ao definidas vari´aveis auxiliares que servir˜ao para compor as 33 regras de tarifac¸a˜ o. Como restric¸a˜ o da linguagem, as vari´aveis utilizadas s´o podem guardar valores num´ericos de ponto flutuante, uma vez que as pol´ıticas tipicamente trabalham com manipulac¸a˜ o de valores deste tipo. A segunda sec¸a˜ o, chamada rules, define as regras de composic¸a˜ o da pol´ıtica de tarifac¸a˜ o por meio de atribuic¸o˜ es, comandos de selec¸a˜ o e operac¸o˜ es aritm´eticas sobre vari´aveis e valores reservados na linguagem. As regras definidas na linguagem representam as regras de neg´ocio da pol´ıtica, e s˜ao definidas em func¸a˜ o dos recursos medidos em cada m´aquina virtual. Ao final da definic¸a˜ o de uma pol´ıtica, utiliza-se a palavra-reservada return, seguida da vari´avel que representa o c´alculo final do custo para uma pol´ıtica de tarifac¸a˜ o, em func¸a˜ o dos valores calculados nas regras. De modo a facilitar a definic¸a˜ o de novas pol´ıticas, podese reutilizar uma pol´ıtica pr´e-definida, similarmente a ideia de heranc¸a (especializac¸a˜ o), bastante conhecida em linguagens de programac¸a˜ o. De modo semelhante, vari´aveis e regras da pol´ıtica pr´e-definida s˜ao reaproveitadas, al´em de se permitir que novas regras e vari´aveis sejam introduzidas ou ainda sobrepostas. Para isso, usa-se, ap´os o nome da pol´ıtica, a palavra reservada extends e em seguida, a pol´ıtica que se quer estender.

if (instance.economiaEnergia >= 0.5 ){ descontoEnergia = 0.03; } if (instance.memoria >= 0.8 ){ descontoUsuario = 0.05; } if (instance.armazenamento >= 0.8 ){ descontoUsuario = 0.04; }

18

} return custo; }

Um aspecto fundamental para a pol´ıtica de tarifac¸a˜ o e´ que a mesma precisa ter acesso aos valores definidos durante a configurac¸a˜ o do servic¸o em relac¸a˜ o aos recursos tarifados e seus respectivos prec¸os. Para este prop´osito, a aCCountSDSL utiliza dois elementos. O primeiro e´ representado pela express˜ao instance.recurso, que representa o valor de um recurso monitorado (Por exemplo, percentual m´edio de uso de mem´oria) em uma instˆancia de uma m´aquina virtual. O segundo e´ representado pelos valores definidos na precificac¸a˜ o dos recursos, e que s˜ao acessados utilizando como prefixo o s´ımbolo $. Esses valores s˜ao recuperados a partir dos componentes do aCCountS-Service. O suporte a` execuc¸a˜ o das pol´ıticas definidas na linguagem aCCountS-DSL e´ feita pelo DSLCompiler. Este componente atua como um compilador, verificando sintaticamente as pol´ıticas e gerando vers˜oes das mesmas para outras linguagens, que ent˜ao podem ser executadas. No caso particular de nossa proposta, o DSLCompiler teve uma grande influˆencia do Xtext5 , um framework open-source para o desenvolvimento de DSLs. O Xtext permite que a partir da definic¸a˜ o das regras de 5 http://www.eclipse.org/Xtext/

sintaxe da linguagem, sejam gerados seus analisadores l´exico e sint´atico, al´em da personalizac¸a˜ o de um gerador de c´odigo, no qual pode-se associar os comandos da DSL desenvolvida com os de alguma outra linguagem de programac¸a˜ o. Especificadamente para o aCCounts, escolheu-se Ruby, uma linguagem de crescente popularidade para desenvolvimento de aplicac¸o˜ es Web de modo a´ gil e r´apido. Por´em, sua caracter´ıstica mais importante para nossa proposta e´ o fato da mesma interpretar dinamicamente seu c´odigo-fonte. Com isso, o c´odigo gerado pelo Xtext pode ser integrado naturalmente ao servic¸o, em tempo de execuc¸a˜ o, permitindo que modificac¸o˜ es nas pol´ıticas sejam refletidas de imediato na tarifac¸a˜ o dos recursos.

vari´aveis e regras. Com isso a pol´ıtica Res1MedUsoPosPlus cont´em onze vari´aveis, sendo dez da pol´ıtica estendida e a d´ecima primeira, a vari´avel local taxaFixa. Esta nova vari´avel representa taxa paga pelo firmamento do contrato de 1 ano, que no contexto da pol´ıtica vale $ 0.0014 mensais. A regra atribu´ıda a` vari´avel custo e´ redefinida, e uma nova pol´ıtica e´ definida com poucas linhas de c´odigo. C´odigo 5. 1 2 3 4 5

No processo de gerac¸a˜ o de c´odigo para uma pol´ıtica de 67 tarifac¸a˜ o, o DSLCompiler entende que as ocorrˆencias instance 8 s˜ao recursos medidos na m´aquina virtual. Estes valores devem 9 ser recuperados no AccountingManager, que atrav´es do nome 10 da vari´avel, retorna os dados dos recursos medidos em uma m´aquina virtual em um determinado per´ıodo. J´a as vari´aveis iniciadas com $ equivalem aos prec¸os dos recursos e, por sua vez, devem ser obtidos no componente ProfileManager, atrav´es da entidade Price, que retorna o prec¸o correspondente ao recurso identificado. Como detalhado na explanac¸a˜ o sobre os componentes do aCCounts, os nomes definidos para os recursos s˜ao previamente configurados no componente ResourcesManager, e para simplificar os processos, o nome do prec¸o e´ , por convenc¸a˜ o, o mesmo nome do recurso. Com isto, o DSLCompiler consegue gerar um c´odigo execut´avel em Ruby, com regras equivalentes a` s definidas na DSL proposta de forma bem simples, uma vez que as construc¸o˜ es da aCCountS-DSL s˜ao restritas a operac¸o˜ es aritm´eticas, comandos de selec¸a˜ o e reutilizac¸a˜ o de regras. Na pol´ıtica SobMedUsoPosPlus, os valores de instance.economiaEnergia e instance.sla s˜ao medidos na m´aquina virtual. Eles representam porcentagens de economia de energia realizada por um usu´ario e de violac¸a˜ o no acordo de servic¸o (por exemplo, tempo que a m´aquina ficou indispon´ıvel), evidenciados na m´aquina virtual respectivamente. Esses valores s˜ao calculados com a finalidade de verificar as configurac¸o˜ es das m´aquinas virtuais do usu´ario e o quanto elas promovem a economia de energia, baseado em an´alises de desempenho [14] e, no caso do SLA, o quanto os acordos de qualidade de servic¸os s˜ao atendidos ou violados. As vari´aveis de instˆancia instance.memoria, instance.cpu, instance.armazenamento, instance.transacaoBD, instance.upload s˜ao medidas de processamento na m´aquina virtual. As vari´aveis descontoEnergia e descontoUsuario s˜ao definidas a partir de comandos de selec¸a˜ o declaradas na pol´ıtica, atendendo a requisitos relacionados ao Bem estar social e Utilit´arios. A taxaCentralDados, definida na pol´ıtica com o valor de $ 0.14 mensais, e´ um valor pago pelo uso das m´aquinas do centro de dados da provedora de nuvem. O C´odigo 5 exemplifica o caso da extens˜ao de uma pol´ıtica pr´e-existente, em que e´ utilizado a palavra reservada extends. Na pol´ıtica Res1MedUsoPosPlus, seu nome evidencia alguns dos requisitos que ela atende: Reservada 1ano (garantia de alocac¸a˜ o), Media (perfil de m´aquina), Uso (forma de contabilizac¸a˜ o), Pos-pago (modelo), Plus (requisitos Utilit´arios e Bem estar social). Ela estende a pol´ıtica SobMedUsoPosPlus, representada na Figura 4 e dessa forma reutiliza todas suas

Pol´ıtica criada por meio da aCCountS-DSL usando extends

Policy Res1MedUsoPosPlus extends SobMedUsoPosPlus{ var { custo, taxaFixa; } rules { taxaFixa = 0.0014; custo = custo + taxaFixa; } return custo; }

Ap´os a configurac¸a˜ o realizada (pol´ıticas definidas por meio da aCCountS-DSL, prec¸os e recursos determinados no perfil das m´aquinas), a execuc¸a˜ o do servic¸o pode ser iniciada para o aCCountS realizar a tarifac¸a˜ o das nuvens que a utiliza. V.

˜ E XPERIMENTAL AVALIAC¸ AO

Para a an´alise da proposta foram realizados experimentos no aCCountS e na aCCountS-DSL, a partir da prototipac¸a˜ o de uma aplicac¸a˜ o Web, utilizando o framework Ruby on Rails. A escolha de Ruby permitiu implementar as interfaces utilizadas pelo agentes como servic¸os Web, com a troca de mensagens obedecendo o formato JSON. Para persistˆencia de dados foi utilizado um banco de dados NoSQL, o MongoDB, que deu suporte a` dinamicidade e desempenho que o servic¸o precisava. As informac¸o˜ es persistidas inclu´ıram as pol´ıticas, as relac¸o˜ es de heranc¸a e os dados de uso das m´aquinas. Do lado do agente tamb´em foi usado o mesmo framework, por´em n˜ao como uma aplicac¸a˜ o Web, mas sim, uma aplicac¸a˜ o convencional executada como uma tarefa no sistema operacional hospedeiro, com periodicidade pr´e-definida. Essas tarefas s˜ao respons´aveis por todas as atividades do agente, requisitando as vari´aveis a serem medidas, coletando dados de uso, efetuando a mediac¸a˜ o e enviando os u´ ltimos ao servic¸o aCCountS. Para armazenamento tempor´ario dos dados no agente, usou-se o banco de dados SQLite, de forma a tornar leve e r´apido o processamento dos dados de uso em cada m´aquina virtual. O prot´otipo pode ser acessado no enderec¸o http://accounts.zn.inf.br. Devido ao uso do framework Ruby on Rails, as principais ideias implantadas por ele foram seguidas no desenvolvimento do prot´otipo, como: (i) DRY (don’t repeat yourself ), estimulando a reutilizac¸a˜ o de c´odigo entre componentes, e (ii) Convention over Configuration (Convenc¸o˜ es sobre Configurac¸o˜ es), de forma a minimizar a necessidade de configurac¸o˜ es para o projeto funcionar, precisando apenas seguir as recomendac¸o˜ es do framework (como nomes de arquivos, localizac¸a˜ o de pastas, etc.). Da mesma forma, alguns padr˜oes de projeto foram adotados durante o desenvolvimento, tanto por o framework influenciar nesse uso, quanto por decis˜oes de projeto para o funcionamento da arquitetura do prot´otipo. S˜ao eles: (i) o padr˜ao MVC (model-view-controller), usado na estruturac¸a˜ o das camadas da aplicac¸a˜ o, tanto no servic¸o quando no agente; (ii) REST (Representational State Transfer), usado no servic¸o para a disponibilizac¸a˜ o de recursos atrav´es de rotas para

acesso do agente; (iii) Singleton, principalmente no agente, que deve ter referˆencia u´ nica para o recebimento de informac¸o˜ es, monitoramento da m´aquina e envio de dados para o servic¸o; (iv) Template Method, tendo seu uso nas classes geradas pelo compilador da DSL, de forma a ter-se m´etodos gen´ericos que se adaptam de acordo com o c´odigo gerado e (v) Observer, acoplado ao padr˜ao MVC e, assim, utilizado na arquitetura do sistema para disparar m´etodos em caso de mudanc¸a de estado em objetos. A Figura 4 ilustra uma funcionalidade: a tela de manipulac¸a˜ o das m´aquinas ou instˆancias do aCCountS-Service. Na parte superior da tela est´a disposto um menu com opc¸o˜ es para o gerenciamento de recursos (variables), perfis (profiles), pol´ıticas (policies) e m´aquinas (machines). Para cada uma destas opc¸o˜ es e´ poss´ıvel criar, alterar e remover itens. No caso da tela apresentada, o administrador da provedora de nuvens pode cadastrar instˆancias, e associ´a-las a uma pol´ıtica de tarifac¸a˜ o e um perfil criados anteriormente, e disponibiliz´a-las aos clientes. O mesmo escolhe, ent˜ao, uma para ser utilizada na tarifac¸a˜ o de sua m´aquina virtual em que o perfil de hardware corresponda suas necessidades. Em nossos testes foram implantadas m´aquinas virtuais em diferentes provedoras de nuvem, cada uma associada a uma pol´ıtica de tarifac¸a˜ o diferente. Por meio desses testes, buscouse mostrar que o fluxo de tarifac¸a˜ o entre os dois componentes (agente e servidor) ocorre de forma correta. Para verificar se a tarifac¸a˜ o tamb´em estava correta, foi realizado o envio de dados de medic¸a˜ o fict´ıcios ao servic¸o, que permitiu comparar os resultados calculados pelo aCCountS com os valores esperados como resposta. A. Avaliac¸a˜ o do aCCountS Para validac¸a˜ o do fluxo de tarifac¸a˜ o foram criadas trˆes m´aquinas virtuais na Amazon e trˆes m´aquinas virtuais no Windows Azure, onde foi implantado o aCCountS-Agent. Associadas a essas m´aquinas, foram criadas trˆes combinac¸o˜ es de pol´ıtica/perfil, de modo que se utilizou as mesmas configurac¸o˜ es nas duas nuvens. As pol´ıticas definidas para cada nuvem e seus perfis correspondentes s˜ao: (i) simplesUsoSobPos, com Garantia de alocac¸a˜ o sob-demanda, Modelo de pagamento p´os-pago, Perfil de m´aquina pequena, Forma de contabilizac¸a˜ o por uso de CPU, mem´oria e armazenamento (Uso CPU/h: $ 0.006, Uso memoria/h: $ 0.006, Uso armazenamento/h: $ 0.006) e taxa de uso da m´aquina ou centro de dados $ 0.14; (ii) simplesTempoSobPos, com Garantia de alocac¸a˜ o sob-demanda, Modelo de pagamento p´os-pago, Perfil de m´aquina pequena, Forma de contabilizac¸a˜ o por tempo de uso da m´aquina (Tempo de uso da m´aquina/h: $ 0.06); e (iii) simplesUsoRes1Pos, com Garantia de alocac¸a˜ o reservada 1 ano (taxa fixa: $ 0.0014), Modelo de pagamento p´os-pago, Perfil de m´aquina pequena, Forma de contabilizac¸a˜ o por uso de CPU, mem´oria e armazenamento (Uso CPU/h: $ 0.0034, Uso mem´oria/h: $ 0.0034, Uso armazenamento/h: $ 0.0034) e taxa de uso da m´aquina ou centro de dados $ 0.14. No experimento, as seis m´aquinas virtuais foram executadas do dia 26 de junho de 2013, a` s 12h e 05 minutos at´e o dia 03 de julho, a` s 4h e 05 minutos e seus registros de medic¸a˜ o (calculados a cada hora) utilizados para validac¸a˜ o do fluxo de tarifac¸a˜ o. Na tabela I s˜ao mostrados seis dos

Tabela I.

R ESULTADOS DOS EXPERIMENTOS REALIZADOS NA Amazon EC2 E Windows Azure

Pol´ıtica (Nuvem) simplesUsoSobPos (Amazon) simplesUsoRes1Pos (Amazon) simplesTempoSobPos (Amazon) simplesUsoSobPos (Azure) simplesUsoRes1Pos (Azure)

simplesTempoSobPos (Azure)

Registro de Medic¸a˜ o {“cpu”: 0.01545, “memoria”: 0.80414, “armazenamento”: 2.7e-05} `‘cpu”=¿0.075, “memoria”=¿0.8302205, “armazenamento”=¿4.1e-05} {“tempoUso”: 1.0}

Reg. Cobranc¸a $ 0.00492

{“cpu”: 0.06428, “memoria”: 0.79215, “armazenamento”: 0.05129} {“cpu”=¿0.06851851851851852, “memoria”=¿0.5443499818181821, “armazenamento”=¿0.05128383636363637} {“tempoUso”:1.0}

$ 0.00545

$ 0.00448 $ 0.06000

$ 0.00366

$ 0.06000

960 registros de medic¸a˜ o recebidos pelo aCCountS-Service (trˆes de cada provedora de nuvem) e os registros de cobranc¸a calculados. Dessa forma, verificou-se a corretude ao passo que os recursos medidos nas m´aquinas foram os previamente definidos no aCCountS-Service e os registros de faturamento foram calculados conforme as definic¸o˜ es nas pol´ıticas e a partir dos dados enviados pelo agente. B. Avaliac¸a˜ o da aCCountS-DSL Para validac¸a˜ o da linguagem aCCountS-DSL foram criadas dez pol´ıticas de tarifac¸a˜ o, combinando os diferentes requisitos apontados nesse trabalho. Cada pol´ıtica de tarifac¸a˜ o foi testada com trˆes conjuntos de valores fixos dos recursos associados a trˆes casos de teste para o sistema. Desta forma, conhecia-se de antem˜ao o valor esperado da fatura. Por meio de um script, esses dados foram enviados para o aCCountS-Service realizar a tarifac¸a˜ o por meio das pol´ıticas definidas no aCCountS-DSL. No experimento foram utilizados trˆes casos de testes (conjuntos de valores fixos dos recursos, os registros de medic¸a˜ o) para verificar a corretude da tarifac¸a˜ o em relac¸a˜ o a` s diferentes pol´ıticas definidas. Estes casos de teste est˜ao definidos na Tabela II. Tabela II. Casos de teste CT1

CT2

CT3

R EGISTROS FIXOS USADOS COMO CASOS DE TESTE Registro { “economiaEnergia”: 0.3, “memoria”: 0.5, “cpu”: 0.5, “armazenamento”: 0.5, “transacaoBD”: 0.5, “upload”: 0.5, “software”: 0.07, “servico”: 0.07, “sla”: 0.03} {“economiaEnergia”: 0.5, “memoria”: 0.8, “cpu”: 0.8, “armazenamento”: 0.8, “transacaoBD”: 0.8, “upload”: 0.8, “software”:0.07, “servico”: 0.07, “sla”:0.0} {“economiaEnergia”: 0.0, “memoria”: 0.3, “cpu”: 0.3, “armazenamento”: 0.3, “transacaoBD”: 0.3, “upload”: 0.3, “software”: 0.14, “servico”: 0.07, “sla”: 0.0}

Na Tabela III podem ser observados os resultados obtidos a partir da aplicac¸a˜ o dos registros especificados como casos de testes mostrados na Tabela II em cada uma das pol´ıticas descritas anteriormente. Tabela III. Pol´ıtica SobMedUsoPosPlus Res1MedUsoPosPlus SobPeqUsoPosPlus SobMedTmpPosPlus

R ESULTADOS OBTIDOS NO EXPERIMENTO Caso de Previsto 0.30070 0.28949 0.28615 0.25220

Teste 1 Obtido 0.30070 0.28949 0.28615 0.25220

Caso de Teste 2 Esperado Obtido 0.30504 0.30504 0.28710 0.28710 0.28272 0.28272 0.25220 0.25220

Caso de Teste 3 Esperado Obtido 0.36800 0.36800 0.36160 0.36160 0.35900 0.35900 0.33000 0.33000

Pelo resultado do experimento, constatou-se que em todos os casos de teste, o servic¸o calcula o valor de tarifac¸a˜ o como

Fig. 4.

Screenshot do prot´otipo da arquitetura aCCounts - associac¸a˜ o entre clientes, perfis e pol´ıticas

esperado. Desta forma, conclui-se que o c´alculo da fatura e´ realizado de forma correta, e que a linguagem aCCountS-DSL pode ser utilizada com seguranc¸a para tarifac¸a˜ o de servic¸os de infraestrutura em computac¸a˜ o em nuvem, definindo regras flex´ıveis. VI.

[3]

˜ E T RABALHOS F UTUROS C ONCLUS OES

A tarifac¸a˜ o de recursos e´ uma caracter´ıstica fundamental da computac¸a˜ o em nuvem. Atrav´es de um levantamento bibliogr´afico foi poss´ıvel verificar que existem muitos desafios de pesquisa relacionados ao tema. Guiado por estes estudos, este trabalho busca melhorar a flexbilidade na definic¸a˜ o de como s˜ao definidos e tarifados os recursos oferecidos por provedores de nuvens de infraestrutura. Foram definidos e apresentados (i) uma arquitetura para sistemas de tarifac¸a˜ o em nuvem independente de um provedor espec´ıfico, (ii) o aCCountS, servic¸o de tarifac¸a˜ o desenvolvido a partir da arquitetura proposta e (iii) uma linguagem de tarifac¸a˜ o flex´ıvel, a aCCountSDSL, que permite definir pol´ıticas de cobranc¸a flex´ıveis para atender diferentes perfis de clientes (necessidades, recursos, perspectivas) e diferentes objetivos das provedoras de nuvem (lucro, bem estar social, prec¸o justo). Com os experimentos realizados no aCCountS e na linguagem aCCountS-DSL, foi mostrado que a partir da arquitetura proposta e´ poss´ıvel desenvolver um sistema capaz de tarifar servic¸os de infraestrutura em nuvem de forma correta e independente. Com base na DSL apresentada, pode-se criar pol´ıticas de tarifac¸a˜ o flex´ıvel e de f´acil modificac¸a˜ o. Dessa forma, esse trabalho atendeu ao seu objetivo, trazendo uma soluc¸a˜ o para os problemas de tarifac¸a˜ o apresentados e, com isso, pˆode contribuir com a a´ rea de tarifac¸a˜ o em computac¸a˜ o em nuvem. Como trabalhos futuros pode-se citar a extens˜ao do servic¸o para atender requisitos de seguranc¸a, disponibilidade e escalabilidade, que s˜ao de suma importˆancia para utilizac¸a˜ o de servic¸o de tarifac¸a˜ o em nuvem. R EFER Eˆ NCIAS [1]

[2]

L. M. Vaquero, L. Rodero-Merino, J. Caceres, and M. Lindner, “A Break in the Clouds: Towards a Cloud Definition,” Rev. Commun. SIGCOMM Comput., vol. 39, no. 1, pp. 50–55, December 2008. [Online]. Available: http://doi.acm.org/10.1145/1496091.1496100

[4]

[5]

[6]

[7]

[8]

[9] [10] [11]

[12]

[13]

[14]

M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. H. Katz, A. Konwinski, G. Lee, D. A. Patterson, A. Rabkin, I. Stoica, and M. Zaharia, “Above the Clouds: A Berkeley View of Cloud Computing,” EECS Department, University of California, Berkeley, Tech. Rep., February 2009. E. da Silva and D. Lucredio, “Software Engineering for the Cloud: A Research Roadmap,” in XXVI Brazilian Symposium on Software Engineering (SBES 2012), Natal-RN, September 2012, pp. 71–80. I. Ruiz-Agundez, Y. Penya, and P. Bringas, “A Flexible Accounting Model for Cloud Computing,” in Annual SRII Global Conference (SRII 2011), San Jose, USA, March 2011, pp. 277–284. F. A. P. da Silva, P. Silveira, V. Garcia, R. Assad, and F. Trinta, “Accounting Models in Cloud and Grid Computing: A Systematic Mapping Study,” in VIII International Conference on Grid Computing and Applications, ser. GCA ’12, Las Vegas, United States, July 2012, p. 7. A. Caracas and J. Altmann, “A pricing information service for grid computing,” in 5th international workshop on Middleware for grid computing: held at the ACM/IFIP/USENIX 8th International Middleware Conference, ser. MGC ’07. New York, NY, USA: ACM, November 2007, pp. 4:1–4:6. [Online]. Available: http: //doi.acm.org/10.1145/1376849.1376853 A. Narayan, S. Rao, G. Ranjan, and K. Dheenadayalan, “Smart metering of cloud services,” in IEEE International Systems Conference (SysCon 2012), Ottawa, Ontario, Canada, March 2012, pp. 1–7. H. S. Group, “Business rule management system,” Website, 2012, http://www.hartmannsoftware.com/pub/Enterprise-RuleApplications/brms. Amazon Web Service, “Amazon Elastic Compute Cloud (Amazon EC2),” Website, 2012, http://aws.amazon.com/pt/ec2/. M. Dantas, ”A l´ogica do capital-informac¸a˜ o”, Contraponto, Ed., 2002. E. Elmroth, F. Marquez, D. Henriksson, and D. Ferrera, “Accounting and billing for federated cloud infrastructures,” in 8th International Conference on Grid and Cooperative Computing (GCC 2009), Lanzhou, China, August 2009, pp. 268–275. I. Ruiz-Agundez, Y. K. Penya, and P. G. Bringas, “A taxonomy of the future internet accounting process,” IV International Conference on Advanced Engineering Computing and Applications in Sciences (ADVCOMP 10), p. 7, October 2010, florence, Italy. Y. Yu and S. Bhatti, “Energy measurement for the cloud,” in International Symposium on Parallel and Distributed Processing with Applications (ISPA 2010), Taipei, Taiwan, september 2010, pp. 619– 624. T. Imada, M. Sato, and H. Kimura, “Power and qos performance characteristics of virtualized servers,” in X IEEE/ACM International Conference on Grid Computing - GRID 2009, Banff, Alberta, Canada, October 2009, pp. 232–240.

Lihat lebih banyak...

Comentários

Copyright © 2017 DADOSPDF Inc.