Estratégias para Uso Eficiente de Recursos em Centros de Dados Considerando Consumo de CPU e RAM

Transcrição

1 UNIVERSIDADE FEDERAL DE GOIÁS INSTITUTO DE INFORMÁTICA PEDRO HENRIQUE PIRES DE CASTRO Estratégias para Uso Eficiente de Recursos em Centros de Dados Considerando Consumo de CPU e RAM Goiânia 2014

2 UNIVERSIDADE FEDERAL DE GOIÁS INSTITUTO DE INFORMÁTICA AUTORIZAÇÃO PARA PUBLICAÇÃO DE DISSERTAÇÃO EM FORMATO ELETRÔNICO Na qualidade de titular dos direitos de autor, AUTORIZO o Instituto de Informática da Universidade Federal de Goiás UFG a reproduzir, inclusive em outro formato ou mídia e através de armazenamento permanente ou temporário, bem como a publicar na rede mundial de computadores (Internet) e na biblioteca virtual da UFG, entendendo-se os termos reproduzir e publicar conforme definições dos incisos VI e I, respectivamente, do artigo 5 o da Lei n o 9610/98 de 10/02/1998, a obra abaixo especificada, sem que me seja devido pagamento a título de direitos autorais, desde que a reprodução e/ou publicação tenham a finalidade exclusiva de uso por quem a consulta, e a título de divulgação da produção acadêmica gerada pela Universidade, a partir desta data. Título: Estratégias para Uso Eficiente de Recursos em Centros de Dados Considerando Consumo de CPU e RAM Autor(a): Pedro Henrique Pires de Castro Goiânia, 04 de Agosto de Pedro Henrique Pires de Castro Autor Dr. Kleber Vieira Cardoso Orientador Dra. Sand Luz Corrêa Co-Orientadora

3 PEDRO HENRIQUE PIRES DE CASTRO Estratégias para Uso Eficiente de Recursos em Centros de Dados Considerando Consumo de CPU e RAM Dissertação apresentada ao Programa de Pós Graduação do Instituto de Informática da Universidade Federal de Goiás, como requisito parcial para obtenção do título de Mestre em Computação. Área de concentração: Ciências da Computação. Orientador: Prof. Dr. Kleber Vieira Cardoso Co-Orientadora: Profa. Dra. Sand Luz Corrêa Goiânia 2014

4 PEDRO HENRIQUE PIRES DE CASTRO Estratégias para Uso Eficiente de Recursos em Centros de Dados Considerando Consumo de CPU e RAM Dissertação defendida no Programa de Pós Graduação do Instituto de Informática da Universidade Federal de Goiás como requisito parcial para obtenção do título de Mestre em Computação, aprovada em 04 de Agosto de 2014, pela Banca Examinadora constituída pelos professores: Prof. Dr. Kleber Vieira Cardoso Instituto de Informática UFG Presidente da Banca Profa. Dra. Sand Luz Corrêa Instituto de Informática UFG Prof. Dr. Fábio Moreira Costa Instituto de Informática UFG Prof. Dr. Lisandro Zambenedetti Granville Instituto de Informática UFRGS

5 Todos os direitos reservados. É proibida a reprodução total ou parcial do trabalho sem autorização da universidade, do autor e do orientador(a). Pedro Henrique Pires de Castro Graduou-se em Ciência da Computação pela Universidade Federal de Goiás ( ). Durante sua graduação, foi bolsista em projetos de pesquisa sob a coordenação do professor Dr. Kleber Vieira Cardoso. No período do mestrado, atuou como bolsista do Projeto FIBRE desenvolvido no INF/UFG em parceria com outras instituições nacionais e estrangeiras. Atua como servidor público federal na área de infraestrutura e segurança da informação.

6 todo esse tempo. À minha família, por prover as condições, ambiente e apoio necessários durante

7 Agradecimentos A Deus pela graça da vida e por tudo que me proporciona. À minha mãe, Eila, por todo amor e dedicação que me oferece sempre. Ao meu irmão, Hebert, pela amizade, pela motivação e pelo apoio. Ao Prof. Kleber V. Cardoso, por sua orientação, amizade e paciência. À Prof. a Sand L. Corrêa, por sua contribuição no trabalho, orientação e apoio. Aos Profs. Fábio Moreira Costa e Lisandro Zambenedetti Granville, pela presença na banca e contribuições à dissertação. Às grandes amizades iniciadas com a vida universitária: Arthur, Calçado, Érika, Vieira, Pessoni e todos os demais; pela amizade, apoio e momentos de descontração. Às grandes amizades que perduraram apesar da vida universitária: Estelia, Daniel, Gercicley e todos os demais: pela amizade, motivação e apoio em cada etapa do processo de realização deste trabalho. Aos colegas do grupo de pesquisa Labora: Barreto, Ottinho, Micael, Lafinha, Bruninho e todos os demais; pela amizade, apoio e momentos de descontração. Aos colegas da Procuradoria da República em Minas Gerais: Renato, Gerson, Ribamar, Leo, Marcus, Alexandre e todos e demais; pela motivação e pelo apoio nos momentos finais deste trabalho. À equipe da secretaria: Mirian, Patrícia e todos os demais; pela atenção, paciência e suporte operacional. Ao INF/UFG, pelas instalações e equipamentos utilizados. À Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES), pelo suporte financeiro.

8 Aquilo que nós mesmos escolhemos é muito pouco: a vida e as circunstâncias fazem quase tudo. John Ronald Reuel Tolkien ( ), Citação atribuída.

9 Resumo de Castro, Pedro Henrique Pires. Estratégias para Uso Eficiente de Recursos em Centros de Dados Considerando Consumo de CPU e RAM. Goiânia, p. Dissertação de Mestrado. Instituto de Informática, Universidade Federal de Goiás. A computação em nuvem tem levado os sistemas distribuídos a um novo patamar, oferecendo recursos computacionais de forma virtualizada, flexível, robusta e escalar. Essas vantagens, no entanto, surgem juntamente com um alto consumo de energia nos centros de dados, ambientes que podem ter até centenas de milhares de servidores. Existem muitas propostas para alcançar eficiência energética em centros de dados para computação em nuvem. Entretanto, muitas propostas consideram apenas o consumo proveniente do uso de CPU e ignoram os demais componentes de hardware, e.g., RAM. Neste trabalho, mostramos o impacto considerável que RAM pode ter sobre o consumo total de energia, principalmente em servidores com grandes quantidades dessa memória. Também propomos três novas abordagens para consolidação dinâmica de máquinas virtuais, levando em conta tanto o consumo de CPU quanto de RAM. Nossas propostas foram implementadas e avaliadas no simulador CloudSim utilizando cargas de trabalho do mundo real. Os resultados foram comparados com soluções do estado-da-arte. Pela adoção de uma visão mais ampla do sistema, nossas propostas não apenas são capazes de reduzir o consumo de energia como também reduzem violações de SLA, i.e., proveem um serviço melhor a um custo mais baixo. Palavras chave Computação em Nuvem, Centro de Dados, Eficiência Energética, Cumprimento de SLA, Consolidação de Máquinas Virtuais

10 Abstract de Castro, Pedro Henrique Pires. <Strategies for Efficient Usage of Resources in Data Centers Considering the Consumption of CPU and RAM>. Goiânia, p. MSc. Dissertation. Instituto de Informática, Universidade Federal de Goiás. Cloud computing is being consolidated as a new distributed systems paradigm, offering computing resources in a virtualized way and with unprecedented levels of flexibility, reliability, and scalability. Unfortunately, the benefits of cloud computing come at a high cost with regard to energy, mainly because of one of its core enablers, the data center. There are a number of proposals that seek to enhance energy efficiency in data centers. However, most of them focus only on the energy consumed by CPU and ignore the remaining hardware, e.g., RAM. In this work, we show the considerable impact that RAM can have on total energy consumption, particularly in servers with large amounts of this memory. We also propose three new approaches for dynamic consolidation of virtual machines (VMs) that take into account both CPU and RAM usage. We have implemented and evaluated our proposals in the CloudSim simulator using real-world traces and compared the results with state-of-the-art solutions. By adopting a wider view of the system, our proposals are able to reduce not only energy consumption but also the number of SLA violations, i.e., they provide a better service at a lower cost. Keywords Cloud Computing, Data Center, Energy Efficiency, SLA Compliance, Virtual Machine Consolidation

11 Sumário Lista de Figuras 11 Lista de Tabelas 13 Lista de Algoritmos 14 Lista de Acrônimos 16 1 Introdução Motivação Objetivos Organização da dissertação 21 2 Consumo energético em centros de dados para computação em nuvem Arquitetura e modelos de negócio Implementações de nuvem Eficiência energética Soluções para centros de dados Soluções de hardware Soluções em software Conclusão 32 3 Modelos e propostas Modelo do sistema Modelo de energia Modelo de energia de CPU Modelo de energia de RAM Mecanismos propostos Detecção de servidores sobrecarregados Detecção de servidores subutilizados 40 Local Underload Detection - LUD 40 Global Underload Detection - GUD 42 Hybrid Underload Detection - HUD Seleção de VMs Alocação de VMs Conclusão 45

12 4 Avaliação dos mecanismos e análise dos resultados Carga de trabalho Métricas Custos de migração Violação de SLA Consumo de energia por RAM Heurísticas cientes de consumo de RAM Seleção de VM por uso de RAM e CPU Parametrização da proposta Comparação Conclusão 69 5 Considerações finais e trabalhos futuros 71 Referências Bibliográficas 74

13 Lista de Figuras 2.1 Arquitetura em camadas da computação em nuvem Modelo de negócios da computação em nuvem Arquitetura do sistema modelado Etapas da consolidação de máquinas virtuais. A região delimitada à esquerda representa o conjunto de etapas nas quais os gerentes locais atuam (servidores), enquanto que a região delimitada à direita representa o conjunto de etapas nas quais o gerente global atua (centro de dados). Os componentes em vermelho representam os subproblemas para os quais este trabalho oferece contribuição Consumo de energia por CPU e RAM. 53 (a) Trace do PlanetLab. 53 (b) Trace da Google primeiros 15 dias Consumo médio de energia por CPU e RAM em função da quantidade de RAM nos servidores. 54 (a) Trace do PlanetLab. 54 (b) Trace da Google primeiros 15 dias Valores de consumo de energia em função do dia avaliado. 55 (a) Trace do PlanetLab 55 (b) Trace da Google primeiros 15 dias Valores de violação de SLA em função do dia avaliado. 56 (a) Trace do PlanetLab 56 (b) Trace da Google primeiros 15 dias Valores de consumo de energia em função do dia avaliado. 58 (a) Trace do PlanetLab 58 (b) Trace da Google primeiros 15 dias Valores de violação de SLA em função do dia avaliado. 59 (a) Trace do PlanetLab 59 (b) Trace da Google primeiros 15 dias Número de servidores ativos no tempo. 60 (a) Trace do PlanetLab. 60 (b) Trace da Google primeiros 15 dias. 60 (c) Trace do PlanetLab. 60 (d) Trace da Google primeiros 15 dias Consumo de energia e SLAV utilizando as abordagens LUD e LUD(L), aplicadas sobre as heurísticas CREW(IQR-MMT) e CREW(LR-MMT), representadas nas figuras (a) e (b), e sobre as heurísticas CREW(IQR- MU) e CREW(LR-MU), representadas nas figuras (c) e (d). 62

14 (a) Trace do PlanetLab, utilizando MMT. 62 (b) Trace do PlanetLab, utilizando MU 62 (c) Trace da Google, utilizando MMT. 62 (d) Trace da Google, utilizando MU Consumo de energia e SLAV utilizando as abordagens GUD e GUD(L), aplicadas sobre as heurísticas CREW(IQR-MMT) e CREW(LR-MMT), representadas nas figuras (a) e (b), e sobre as heurísticas CREW(IQR- MU) e CREW(LR-MU), representadas nas figuras (c) e (d). 63 (a) Trace do PlanetLab, utilizando MMT. 63 (b) Trace do PlanetLab, utilizando MU. 63 (c) Trace da Google, utilizando MMT. 63 (d) Trace da Google, utilizando MU Consumo de energia e SLAV utilizando as abordagens HUD e HUD(L), aplicadas sobre as heurísticas CREW(IQR-MMT) e CREW(LR-MMT), representadas nas figuras (a) e (b), e sobre as heurísticas CREW(IQR- MU) e CREW(LR-MU), representadas nas figuras (c) e (d). 64 (a) Trace do PlanetLab, utilizando MMT. 64 (b) Trace do PlanetLab, utilizando MU. 64 (c) Trace da Google, utilizando MMT. 64 (d) Trace da Google, utilizando MU Melhoria do desempenho alcançado, em percentual, pelas estratégias UD em comparação à aplicação isolada de CREW. Nos gráficos, são apresentados apenas os resultados para os parâmetros que mostraram o maior ganho em ESV. As estratégias foram aplicadas sobre a carga de trabalho do PlanetLab. 65 (a) Aplicação sobre CREW(IQR-MMT). 65 (b) Aplicação sobre CREW(IQR-MU). 65 (c) Aplicação sobre CREW(LR-MMT). 65 (d) Aplicação sobre CREW(LR-MU) Melhoria do desempenho alcançado, em percentual, pelas estratégias UD em comparação à aplicação isolada de CREW. Nos gráficos, são apresentados apenas os resultados para os parâmetros que mostraram o maior ganho em ESV. As estratégias foram aplicadas sobre a carga de trabalho da Google. 65 (a) Aplicação sobre CREW(IQR-MMT). 65 (b) Aplicação sobre CREW(IQR-MU). 65 (c) Aplicação sobre CREW(LR-MMT). 65 (d) Aplicação sobre CREW(LR-MU). 65

15 Lista de Tabelas 2.1 Características da literatura revisada Consumo de energia, em Watts, em função do percentual de utilização de CPU Consumo de energia, em Watts, e tempo de latência em função do modo de operação da RAM. A latência é medida, na maioria dos estados, em função do tempo de relógio (tck). Os valores da tabela se referem à arquitetura DDR MHz Principais características das heurísticas utilizadas na consolidação de VMs Tamanhos das VMs Sumário dos dados da carga de trabalho do PlanetLab: número de VMs e estatísticas da utilização de CPU Sumário dos dados da carga de trabalho da Google: número de VMs e estatísticas da utilização de CPU Valores médios de violação geral de SLA Sumário dos resultados de todas as métricas para a carga de trabalho do PlanetLab Sumário dos resultados de todas as métricas para a carga de trabalho da Google. 68

16 Lista de Algoritmos 3.1 Local Underload Detection - LUD Global Underload Detection - GUD Hybrid Underload Detection - HUD Maximum Utilization - MU CPU and RAM Energy aware - CREW 46

17 Lista de Acrônimos BFD Best Fit Decreasing. 42 CREW CPU and RAM Energy aware. 17 DCD Dynamic Component Deactivation. 25 DVFS Dynamic Voltage and Frequency Scaling. 15 EWMA Exponential Weighted Moving Average. 37 GUD Global Underload Detection. 37 GUD(L) Global Underload Detection with Lists. 58 HUD Hybrid Underload Detection. 37 HUD(L) Hybrid Underload Detection with Lists. 58 IaaS Infrastructure as a Service. 20 IQR Interquartile Range. 36 LR Local Regression. 36 LRR Local Regression Robust. 36 LUD Local Underload Detection. 37 LUD(L) Local Underload Detection with Lists. 58 MAD Median Absolute Deviation. 36 MC Maximum Correlation. 41 MMT Minimum Migration Time. 41 MU Maximum Utilization. 17, 41 NAS Network Attached Storage. 31 NPA Non Power Aware - NPA. 63 PaaS Platform as a Service. 20 PDM Performance Degradation due to Migration. 49 PUE Power Usage Effectiveness. 23 QoS Quality of Service. 16

18 Acronyms 16 RAM Random Access Memory. 16 RC Random Choice. 41 SaaS Software as a Service. 21 SLA Service Level Agreement. 16 SLATAH SLA violation Time per Active Host. 49 SLAV SLA Violation. 49 UD Underload Detection. 17 VMM Virtual Machine Monitor. 26 VMs Virtual Machines. 16 VPN Virtual Private Network. 22

19 Introdução CAPÍTULO 1 Na década de 1960, John McCarthy, cientista da computação estadunidense, já previa a possibilidade de instalações computacionais virem a ser oferecidas ao público em geral na forma de serviço [61]. Esse conceito deu origem ao modelo conhecido por utility computing, no qual os recursos computacionais são oferecidos sob demanda ao usuário e o custo é baseado na sua utilização (pay-as-you-go), assim como acontece com os serviços de eletricidade e telecomunicações [5, 78]. A computação em nuvem surge como uma realização da utility computing. A disponibilização de infraestruturas computacionais através de um modelo em nuvem permite o acesso remoto a uma coleção de recursos virtuais que inclui processamento, memória, armazenamento e comunicação de dados [73]. Esse modelo computacional tem se mostrado adequado para atender a diversos tipos de necessidades, desde o usuário doméstico que necessita apenas de um pequeno disco virtual até o usuário corporativo que terceiriza processamento e armazenamento em larga escala. Dessa forma, o usuário se torna isento do alto custo de aquisição de uma infraestrutura que seja grande o suficiente para atender possíveis picos de demanda. Além disso, tornam-se também ônus do provedor os custos de manutenção e a complexidade de administração da infraestrutura. 1.1 Motivação Por um lado, a computação em nuvem tem levado o conceito de sistemas distribuídos a um novo patamar, oferecendo recursos computacionais virtualizados com flexibilidade, confiança e escalabilidade sem precedentes. Por outro lado, a demanda energética da computação em nuvem exige atenção [13], e tópicos tais como o desperdício de energia têm conduzido a esforços acadêmicos e industriais para alcançar melhor eficiência energética nas infraestruturas computacionais [54, 62, 68]. A base dos sistemas de computação em nuvem são os centros de dados que podem conter até centenas de milhares de servidores. Além dos equipamentos de computação, como servidores, storages e switches, os centros de dados contam também com

20 1.1 Motivação 18 enormes sistemas de refrigeração que podem chegar a consumir metade de toda a energia da infraestrutura [55]. No Brasil, o custo médio da energia elétrica, em kwh, é de R$ 0,34 [4]. Isso significa que a redução de 1 kwh no consumo anual representaria uma economia de aproximadamente R$ 2.970,00. Nesse contexto, a eficiência energética no uso dos recursos computacionais pode implicar em uma sensível redução dos custos de operação de um centro de dados. A redução no consumo de energia elétrica também tem impacto ambiental positivo, o qual é relevante na escala que envolve os centros de dados. De acordo com um relatório do Greenpeace [41], em 2011, os centros de dados consumiam 2% da energia elétrica global e o consumo crescia a uma taxa de 12% ao ano. O conceito de gerenciamento de recursos computacionais com ênfase em eficiência energética foi aplicado inicialmente no contexto de dispositivos móveis alimentados por bateria. Nesse cenário, o consumo energético deve ser minimizado a fim de se aumentar o tempo de vida da bateria [8]. Embora servidores e centros de dados possam utilizar técnicas desenvolvidas para dispositivos móveis, esses sistemas requerem métodos específicos. Ainda assim, um aspecto comum entre os dispositivos eletrônicos pode ser observado: para lidar com o problema de alto consumo de energia é necessário eliminar as ineficiências e desperdícios na forma com que a eletricidade é fornecida aos dispositivos. Nos centros de dados, o consumo energético é afetado por dois fatores principais. Primeiro, do ponto de vista do hardware, existem duas questões: uma em relação à quantidade de recursos computacionais ativos e outra a respeito da ineficiência energética de seus componentes físicos. Estudos mostram que mesmo quando estão ociosos, os servidores podem consumir até cerca de 70% da energia que é necessária durante o período de pico de trabalho [27]. Uma maneira de lidar com a ineficiência energética de componentes físicos é o estabelecimento de um sistema computacional que mantenha seu funcionamento de maneira proporcional à demanda de utilização por parte de aplicações. Isso tem sido feito através de soluções em hardware e firmware, adotando abordagens tais como escalonamento dinâmico de voltagem e frequência Dynamic Voltage and Frequency Scaling (DVFS) [3, 77, 79, 80]. Outro fator no problema do consumo energético, agora do ponto de vista do software, é a ineficiência no uso dos recursos computacionais. Estudo feito com mais de 5000 servidores de produção, durante um período de seis meses, mostrou que, mesmo quando não estão ociosos, a utilização de servidores raramente se aproxima de 100% [7]. Verificou-se que, na maior parte do tempo, a utilização dos servidores fica entre 10% e 50% de sua capacidade máxima, consumindo energia e gerando calor desnecessariamente. A subutilização de recursos computacionais é um problema que tem sido tratado

21 1.1 Motivação 19 no contexto da virtualização [10, 16, 28, 40, 47, 57, 74, 83]. Basicamente, essa solução consiste em criar máquinas virtuais Virtual Machines (VMs) que atendam à demanda do centro de dados e consolidá-las em um número mínimo de servidores. Como a demanda por recursos computacionais em infraestruturas em nuvem é elástica [15], é importante que o processo de consolidação das VMs, ou seja, sua distribuição entre os servidores, seja dinâmico, com o intuito de atender às necessidades correntes. A utilização de migração ao vivo (live migration) [18] das VMs permite que esse processo de consolidação seja transparente, diminuindo ainda o impacto no desempenho das VMs. Na consolidação de VMs, o processo de migração é comumente utilizado em dois cenários distintos: servidores sobrecarregados e servidores subutilizados. No caso de servidores estarem sobrecarregados, é realizada a migração de apenas algumas máquinas virtuais - apenas o necessário para retirar o servidor da condição de sobrecarregado, seja qual for a definição desse estado. Aqui, a migração objetiva evitar degradação de desempenho das máquinas virtuais, o que poderia levar à violação da qualidade de serviço Quality of Service (QoS) requerida. Caso um servidor seja considerado subutilizado, todas as máquinas virtuais que estão sendo executadas nele serão migradas para outros servidores. Dessa forma, o servidor, que passa a estar ocioso, pode ser desligado ou colocado em modo de dormência, reduzindo assim o consumo energético. É preciso notar que o número mínimo de servidores ativos também precisa ser controlado como parte da solução para assegurar o cumprimento do acordo de nível de serviço Service Level Agreement (SLA) estabelecido entre o provedor da nuvem e seus usuários [15]. Se os requisitos computacionais de uma aplicação não são satisfeitos, a aplicação poderá enfrentar problemas como aumento no tempo de resposta, estouro de temporizadores (timeouts) ou falhas. A consolidação de VMs com foco em eficiência energética pode ser formulado como um problema de alocação de recursos computacionais no qual o objetivo é minimizar o consumo de energia atendendo os requisitos de qualidade de serviço, definidos em termos de SLA. Tradicionalmente, a abordagem utilizada na consolidação de VMs tem sido minimizar o consumo energético de apenas um tipo de recurso, i.e., CPU [10, 11, 47, 57, 74]. No entanto, o crescimento de arquiteturas com múltiplos núcleos e a própria virtualização têm exigido servidores equipados com grandes quantidades de memória Random Access Memory (RAM), tornando representativo o consumo energético por parte desse recurso [42, 50, 52]. Neste trabalho, utilizamos RAM como um sinônimo para memória primária no servidor, independentemente da tecnologia utilizada. Em 2009, Lin et al. [52] e Barroso et al. [42] já constatavam que o consumo de energia proveniente do uso de RAM correspondia a um valor entre 25% e 40% do consumo total de um servidor. De fato, esse valor pode ser ainda superior, uma vez que

22 1.2 Objetivos 20 essa estimativa não inclui o consumo de energia pelos controladores de memória [22]. Ante tais colocações, esta dissertação possui como objetos de estudo o impacto da RAM no consumo energético de servidores de centros de dados e a busca de um compromisso entre economia de energia e manutenção do SLA. 1.2 Objetivos Neste trabalho, são apresentadas três propostas para aperfeiçoar a consolidação de VMs com foco em eficiência energética e manutenção de SLA de centros de dados para computação em nuvem. Inicialmente, é proposta uma heurística chamada CPU and RAM Energy aware (CREW), a qual utiliza um modelo de energia que considera conjuntamente o consumo proveniente do uso de CPU e de RAM com a finalidade de definir a alocação de VMs que resulte no menor consumo de energia possível. É apresentada também uma nova abordagem para detecção de servidores subutilizados, chamado Underload Detection (UD), que se baseia no histórico de utilização de CPU para estabelecer um limiar mínimo para desligamento ou adormecimento de servidores. Além disso, é proposto um mecanismo de seleção de máquinas virtuais para migração, chamado Maximum Utilization (MU), que utiliza como parâmetros o tempo de migração de uma máquina virtual conjuntamente com sua utilização de CPU. A implementação e avaliação das propostas é feita no simulador CloudSim, utilizando carga de trabalho real proveniente de VMs do PlanetLab [66] e de um cluster da empresa Google [39]. Os resultados mostram que, comparadas com outras estratégias da literatura, as propostas deste trabalho reduzem o consumo de energia e aumentam a garantia de QoS. Os seguintes objetivos foram estabelecidos para este trabalho: 1. Investigar o impacto da utilização de RAM sobre o consumo energético total de um servidor típico de centros de dados. 2. Propor um modelo analítico para quantificar o consumo energético em função da utilização de RAM. 3. Propor e implementar mecanismos para consolidação de máquinas virtuais que façam uso do consumo energético por utilização de CPU e RAM, conjuntamente, como parâmetros da tomada de decisão. 4. Avaliar e comparar as propostas com outras estratégias da literatura, tendo como principais métricas de avaliação o consumo de energia e a manutenção de SLA.

23 1.3 Organização da dissertação Organização da dissertação O restante desta dissertação está organizado da seguinte forma: No Capítulo 2 são apresentados os principais conceitos a respeito de computação em nuvem e são comentados alguns importantes trabalhos dentro do contexto desta dissertação. No Capítulo 3 é apresentado o modelo de sistema bem como os modelos de energia que quantificam o consumo por CPU e RAM considerados neste trabalho. Além disso, é apresentada uma descrição detalhada das soluções propostas para consolidação de máquinas virtuais com foco no compromisso entre consumo energético e manutenção de SLA. A avaliação das propostas, a comparação com outras estratégias e os resultados das simulações realizadas são o foco do Capítulo 4. Por fim, o Capítulo 5 apresenta um resumo dos resultados obtidos e conclusões e discute possíveis direções para trabalhos futuros.

24 CAPÍTULO 2 Consumo energético em centros de dados para computação em nuvem Computação em nuvem pode se referir tanto às aplicações que são fornecidas na forma de serviços por meio da Internet quanto ao hardware e os sistemas computacionais sobre os quais essas aplicações são executadas. No entanto, não existe um consenso para o que é exatamente a computação na nuvem. O trabalho apresentado por Vaquero et al [73], por exemplo, compara mais de 20 diferentes definições de variadas fontes. A dificuldade de se estabelecer um conceito padrão para a computação em nuvem consiste no fato de que ela, por si só, representa não apenas uma nova tecnologia, mas também um modelo de negócio e de operações que une diferentes tecnologias [73]. De fato, a maior parte das tecnologias utilizadas não são novas. Semelhante à computação em grade, a computação em nuvem utiliza recursos distribuídos para alcançar objetivos no nível da aplicação [30]. Diferencia-se, no entanto, ao utilizar tecnologias de virtualização para compartilhamento e aprovisionamento dinâmico de recursos [82]. A computação em nuvem pode ser vista também como uma realização da utility computing, a qual representa o modelo de provisão de recursos sob demanda e precificação baseada em uso. Em outras palavras, o serviço vendido na computação em nuvem é a utility computing [31]. A computação autonômica também pode ser encontrada nesse conjunto de tecnologias, uma vez que a provisão de recursos, na computação em nuvem, é automática. Na computação autonômica, no entanto, o objetivo maior é a diminuição da complexidade de gerenciamento [45], enquanto que na computação em nuvem, o foco se encontra na redução de custos. Apesar da falta de um conceito estrito para computação em nuvem como um todo, alguns aspectos de sua realização, tais como arquitetura, modelos de negócio e implementação, possuem uma estrutura mais bem definida, permitindo uma descrição mais adequada. Assim, as seções subsequentes deste capítulo visam apresentar os principais conceitos a respeito de computação em nuvem, bem como alguns importantes trabalhos dentro do contexto desta dissertação.

25 2.1 Arquitetura e modelos de negócio Arquitetura e modelos de negócio A arquitetura de um ambiente de computação em nuvem pode ser dividida em quatro camadas: hardware ou centro de dados, infraestrutura, plataforma e aplicação [82]. Essa arquitetura é ilustrada na Figura 2.1. Figura 2.1: Arquitetura em camadas da computação em nuvem. A camada de hardware compreende os recursos físicos do centro de dados, tais como servidores, roteadores, switches e sistema de refrigeração. Questões relacionadas a componentes físicos são tratadas nessa camada, por exemplo, configuração de tolerância a falhas, gerenciamento de tráfego e gerenciamento de consumo de energia. A camada de infraestrutura compreende a camada de virtualização dos recursos. Os recursos computacionais são particionados e atribuídos dinamicamente aos usuários através de tecnologias de virtualização como Xen [81], KVM [48], VMware [75] e Open vswitch [64]. Vale ressaltar que o gerenciamento de consumo de energia extrapola a camada de hardware, sendo também realizado na camada de infraestrutura, através da consolidação de VMs. Essas duas camadas, hardware e infraestrutura, podem ser oferecidas ao usuário como um serviço. Trata-se do modelo de negócio denominado Infraestrutura como um Serviço Infrastructure as a Service (IaaS). Nessa modalidade, os recursos computacionais são aprovisionados sob demanda, geralmente em termos de máquinas virtuais. São exemplos de provedores IaaS: Amazon EC2 [2], GoGrid [36] e Flexiscale [29]. Sistemas operacionais e arcabouços de aplicação são elementos encontrados na camada de plataforma. Como alternativa a oferecer uma infraestrutura virtualizada, é possível prover a plataforma de software, ou seja, um ambiente de desenvolvimento, sobre o qual os sistemas executam. Assim, o próprio usuário pode criar e hospedar suas aplicações. O tratamento de requisitos de hardware é feito de maneira transparente. Esse modelo é conhecido por Plataforma como um Serviço Platform as a Service (PaaS). Exemplos de PaaS incluem Google App Engine [37] e Microsoft Windows Azure [6]. Por fim, é na camada de aplicação que se encontram as aplicações em nuvem. Essas aplicações são acessadas através de serviços Web, através de uma API, por exemplo,

26 2.2 Implementações de nuvem 24 XMLRPC ou REST, ou através de uma interface de usuário Web. Dessa forma, não é necessário ao usuário possuir uma infraestrutura física. Além de diminuir a complexidade de manutenção por parte do cliente, o provedor possui a oportunidade de diminuir os custos compartilhando os recursos com um grande número de usuários. Essa modalidade é chamada de Software como um Serviço Software as a Service (SaaS). Um exemplo de serviço nesse modelo é o Google Apps [38]. Os modelos de negócio supracitados constituem o conjunto de serviços mais comumente encontrado na literatura. Naturalmente, existem outros modelos de negócio. No entanto, a descrição desses modelos está além do escopo deste trabalho. No que se refere ao papel de provisão, o ambiente de computação pode ser organizado da seguinte forma: em uma camada, tem-se o provedor de infraestrutura, que gerencia a plataforma em nuvem e atribui recursos conforme um modelo de precificação baseado em uso; os recursos computacionais são então entregues ao provedor de serviço, que aluga recursos de um ou mais provedores de infraestrutura e os oferece como serviço ao usuário final. Essa organização é ilustrada na Figura 2.2. Figura 2.2: Modelo de negócios da computação em nuvem. 2.2 Implementações de nuvem Algumas questões devem ser consideradas ao se decidir por utilizar um ambiente em nuvem. Enquanto alguns provedores de serviço podem optar pela diminuição dos custos operacionais, outros podem se concentrar em fornecer maiores níveis de segurança e confiabilidade, por exemplo. Naturalmente, diferentes modelos de implementação oferecem diferentes benefícios e vantagens. Os modelos nos quais uma nuvem pode ser implementada são: nuvem pública, nuvem privada, nuvem híbrida e nuvem privada virtual. Esses modelos são descritos a seguir. O modelo em que os serviços são implementados na infraestrutura do provedor de serviço e são entregues através da Internet, sob demanda, é chamado de nuvem

27 2.3 Eficiência energética 25 pública. Da elasticidade desse modelo, isto é, da possibilidade de se adicionar ou remover recursos dinamicamente ao conjunto provido para o usuário, surge a necessidade de grandes centros de dados. A principal vantagem desse modelo é que, para o usuário, não é necessário investimento para criar e manter a infraestrutura. Tudo é terceirizado e, em geral, a escolha ou troca de fornecedor é similar a de outros serviços convencionais. No entanto, desse modelo incorrem desafios relacionados à segurança da informação e à qualidade do serviço, uma vez que o compartilhamento dos recursos e o controle físico é realizado pelo fornecedor da infraestrutura [33, 76, 78, 82]. A abordagem oposta ao modelo de nuvem pública é a chamada nuvem privada. Nesse modelo, a infraestrutura é planejada para atender a uma única organização. A infraestrutura pode ser implementada internamente, isto é, pela própria organização, ou mesmo por um provedor externo, sem compartilhamento dos recursos com outras organizações. O benefício desse modelo está no alto grau de controle sobre os recursos, o que permite uma manutenção mais ágil e flexível no que se refere a quesitos como desempenho, confiabilidade e segurança. No entanto, perdem-se a elasticidade, dada a limitação dos recursos disponíveis, e o baixo custo encontrados no modelo público [33, 76, 78, 82]. O modelo de nuvem híbrida consiste na combinação dos dois modelos anteriormente citados, buscando obter as vantagens de ambos. Nessa abordagem, parte da infraestrutura de serviço é implementada em nuvem pública enquanto a outra parte é implementada em nuvem privada. De maneira geral, os serviços e dados críticos e sigilosos são mantidos na nuvem privada. Dessa forma, é possível estabelecer níveis mais altos de controle se comparado à nuvem pública, mantendo ainda a elasticidade da nuvem [33, 76, 78, 82]. Uma outra implementação é o modelo chamado nuvem privada virtual. Esse modelo consiste em um plataforma mantida sobre nuvens públicas que, fazendo uso de redes privadas virtuais Virtual Private Network (VPN), permite ao provedor de serviço projetar sua própria topologia e configurações de segurança. Dessa forma, a nuvem privada virtual permite a virtualização em vários níveis, de servidores à rede de comunicação [82]. 2.3 Eficiência energética Conforme introduzido no capítulo anterior, o aumento na demanda por utilização de recursos computacionais trouxe consigo um aumento físico inevitável no tamanho de centros de dados. Esse aumento estrutural e, consequentemente, o aumento no consumo energético dessas infraestruturas têm sido objeto de preocupação e estudos, tanto no que se refere ao impacto econômico causado quanto ao impacto ambiental [41, 63, 78]. O

28 2.3 Eficiência energética 26 conjunto de soluções propostas, no contexto da tecnologia da informação, com o objetivo de diminuir o impacto ambiental tem sido chamado de TI verde (green IT) [78]. As subseções subsequentes descrevem alguns princípios e técnicas utilizados, bem como trabalhos recentes, cujo objetivo é aumentar a eficiência energética de recursos computacionais, tanto em soluções de hardware quanto em software Soluções para centros de dados A base dos sistemas de computação em nuvem são os centros de dados que podem conter até centenas de milhares de servidores. Além dos equipamentos de computação, como servidores, storages e switches, os centros de dados contam também com enormes sistemas de refrigeração, que podem chegar a consumir metade de toda a energia da infraestrutura [55]. A razão entre o consumo total de energia de um centro de dados e a parte da energia consumida em um centro de dados que é efetivamente demandada por equipamentos de TI tem sido expressa em um parâmetro denominado Power Usage Effectiveness (PUE). Esse parâmetro representa a eficiência energética da infraestrutura. De acordo com Garg et al. [33], os valores típicos para PUE de centros de dados atuais variam de 1,3 a 3,0. No entanto, como reportado pelo projeto Open Compute [58], por exemplo, o centro de dados do Facebook em Oregon (EUA) alcançou no final de 2013 um PUE de 1,09, o que significa que 92% do consumo energético total do centro de dados é feito por recursos computacionais. É importante notar que a principal causa da baixa eficiência energética de um centro de dados encontra-se na baixa utilização média dos recursos computacionais. Estudos mostram que a utilização média de um servidor oscila entre 10% a 50% [7]. A existência de um conjunto de recursos computacionais tão acima da demanda média de utilização é justificada pela necessidade de estabelecer um ambiente capaz de lidar com picos de carga. Apesar de tal cenário de pico acontecer efetivamente com baixa frequência, é necessário assegurar que o desempenho não seja prejudicado, o que aconteceria, por exemplo, caso uma aplicação fosse executada sobre um servidor sobrecarregado. Em 2007, Fan et al. [27] constataram que, mesmo quando estavam ociosos, os servidores consumiam cerca de 70% da energia que era necessária durante o período de pico de trabalho. De acordo com os dados obtidos através do benchmark SPECpower [71], as configurações de servidores projetados ao final de 2013 consomem cerca de 20% a 30% da energia quando ociosos. Apesar da redução significativa desse consumo, causada principalmente pelo desenvolvimento de arquiteturas mais eficientes, manter um servidor ligado com um baixo nível de utilização ainda é altamente ineficiente do ponto de vista do consumo de energia.

29 2.3 Eficiência energética 27 A abordagem mais comum utilizada para lidar com essa ineficiência em centros de dados tem sido a distribuição da carga de trabalho no menor número possível de servidores, concentrando a carga em alguns e desligando os demais [7, 8, 9, 10, 17, 25, 33, 35, 47, 56, 57, 65, 67, 72, 74]. Desse método incorre, no entanto, a preocupação com o pico de trabalho, que é imprevisível, dada a dinamicidade característica de cargas de trabalho em ambientes em nuvem. Assim, cabe ao provedor da infraestrutura lidar com o compromisso entre alcançar maior economia de energia e garantir a qualidade de serviço Soluções de hardware O consumo energético nos componentes de hardware pode ser classificado em estático e dinâmico [12]. O consumo estático de energia é causado pelas correntes de fuga em quaisquer circuitos ativos. Esse consumo está diretamente relacionado ao tipo de transistores, circuitos e nível lógico utilizados no projeto do equipamento. Para lidar com ineficiência energética nesse nível, faz-se necessário um novo projeto da arquitetura do hardware. O consumo dinâmico refere-se à atividade nos circuitos (e.g., comutação de estados, alteração de valores nos registradores) e depende principalmente do cenário de uso, frequência de relógio (ou clock) e atividade de entrada/saída [12]. Suas principais fontes são correntes de curto-circuito e capacitância comutada. As correntes de curtocircuito são responsáveis por 10% a 15% do consumo de energia. No entanto, qualquer medida de redução desse consumo implica em degradação de desempenho [12]. Logo, a capacitância comutada é a fonte primária de consumo dinâmico de energia. Assim, o consumo dinâmico de energia pode ser expresso como: C din = acv 2 f, (2-1) onde a é a atividade de comutação, C é a capacitância física, V é a tensão de alimentação e f é a frequência de relógio [12]. Uma vez que os valores da atividade de comutação e da capacitância física são determinados no projeto em baixo nível do sistema, são a tensão de alimentação e a frequência de relógio os elementos que oferecem as melhores oportunidades de aumentar a eficiência energética do hardware. Uma técnica largamente adotada utiliza a possibilidade combinada de se alterar tensão de alimentação e frequência de relógio de acordo com a utilização. Essa técnica é chamada DVFS (Dynamic Voltage and Frequency Scaling) e foi amplamente abordada na literatura [14, 16, 25, 32, 34, 46, 56, 57, 67, 74]. Embora a frequência de CPU possa ser ajustada de forma independente, ela por si só não conduz a grandes reduções de consumo. Resultado mais efetivo é alcançado pela alteração da tensão de alimentação combinada com a alteração de frequência. Isso se deve

30 2.3 Eficiência energética 28 tanto ao fato de a tensão ter impacto não linear (V 2 ), bem como o fato de processadores atuais apresentarem desempenho satisfatório mesmo em níveis baixos de tensão. Em um caso ideal, a aplicação do DVFS implica em uma redução cúbica do consumo dinâmico de energia. Para CPU, o DVFS permite que, em modo de baixa atividade, o consumo de energia atinja menos de 30% em comparação ao estado de pico de trabalho, obtendo assim uma variação no consumo em mais de 70% [7]. No caso dos demais dispositivos computacionais, essa variação é menor: menos do que 50% para DRAM [22], 25% para discos, 15% para componentes de rede e negligenciável para os demais componentes [12]. A técnica DVFS atua sobre a redução do número de instruções com as quais um processador pode lidar, seja utilizando histórico de demandas anteriores e/ou prevendo estados posteriores. Em qualquer caso, esse comportamento diminui seu desempenho. Em um cenário como o da computação em nuvem, no qual a carga de trabalho é dinâmica e, a priori, imprevisível, a utilização dessa técnica, apesar de alcançar níveis consideráveis de economia no consumo de energia, pode incorrer em degradação da qualidade do serviço oferecido. Uma outra abordagem, ainda dentro do contexto de técnicas a serem aplicadas sobre o consumo dinâmico de energia, é a desativação dinâmica de componentes Dynamic Component Deactivation (DCD). Essa técnica é aplicada sobre componentes computacionais sobre os quais não é possível estabelecer um funcionamento proporcional à carga. Nesse caso, a alteração do componente consiste na sua desativação. De acordo com David et al. [20], existem oito estados possíveis para RAM: 1) de prontidão (standby) ativa, 2) de prontidão com pré-carga, 3) desligado (powerdown) ativo, 4) desligado com pré-carga rápida, 5) desligado com pré-carga lenta, 6) desligado com pré-carga lenta e registradores desligados, 7) auto-atualizado (self-refresh), e 8) autoatualizado com registradores desligados. Desses estados, prontidão ativa é o que consome mais energia; porém, é o único estado no qual a memória consegue realizar operações de leitura e escrita de imediato. Os demais, embora consumam uma quantidade menor de energia, já apresentam níveis de latência devido à transição entre os estados. Embora seja comum que um servidor mantenha alto o nível de utilização da RAM, diversos trabalhos propõem abordagens para se beneficiar de ociosidade de RAM e economizar energia através da comutação de estados [21, 24, 26, 43, 49, 51, 59]. No entanto, a técnica DCD pode levar a dois problemas, sendo um em relação ao desempenho e outro em relação ao consumo energético. A reativação dos componentes pode não atender a demanda de utilização, causando degradação de desempenho, uma vez que a disposição dos recursos para utilização não é imediata. Além disso, a reativação de componentes consome uma quantidade de energia maior do que a consumida no estado normal de funcionamento. Dessa forma, em um cenário em que o tempo durante o qual o

31 2.3 Eficiência energética 29 componente esteve desativado foi excessivamente curto, a economia energética alcançada pela desativação do componente passa a ser insatisfatória Soluções em software Existe uma vasta literatura a respeito de gerenciamento de energia em centros de dados que proveem recursos virtuais [10, 11, 16, 28, 40, 47, 57, 74, 83]. Um dos primeiros trabalhos nesse contexto foi realizado por Nathuji e Schwan [57]. Os autores propuseram uma arquitetura na qual gerentes global e locais são combinados a fim de prover um sistema de alocação de recursos ciente do consumo de energia. O gerente local reside em cada servidor físico e aplica políticas no nível do sistema operacional para controlar o consumo de energia. Periodicamente, o gerente global obtém, dos gerentes locais, informação a respeito do uso dos recursos e dinamicamente ajusta a alocação de VMs usando migração ao vivo. A migração ao vivo de uma VM é o processo de transferir as páginas de memória de uma máquina virtual de um servidor físico para outro em tempo de execução [18]. Nesse processo, o hipervisor ou monitor de máquina virtual, Virtual Machine Monitor (VMM) inicialmente faz uma cópia das páginas de memória e então as transfere em várias rodadas. Esse processo se inicia pelas páginas de memória menos utilizadas. Para a cópia das páginas de memória mais utilizadas, a execução da VM é interrompida, ocasionando um período de indisponibilidade (downtime). Tão logo todas as páginas de memória tenham sido transferidas para o servidor de destino, a VM pode então voltar ao estado de execução. Observa-se que o objetivo da migração ao vivo é realizar a transferência da VM no menor tempo de indisponibilidade possível. Beloglazov et al. [10] dividiram o problema da consolidação de VMs ciente de energia em quatro subproblemas: detecção de sobrecarga nos servidores, detecção de subutilização nos servidores, seleção de VMs e alocação de VMs. Para resolver o primeiro subproblema, os autores propuseram diferentes limiares adaptativos de utilização, os quais são baseados em análises estatísticas dos dados históricos de utilização de CPU. Para determinação de subutilização dos servidores, o sistema seleciona o servidor com menor utilização de CPU. O problema da seleção de VMs é tratado utilizando-se migração ao vivo da VM que requer o menor tempo para completar a migração. O problema da alocação de VMs é modelado como o problema clássico bin-packing com diferentes tamanhos de contêineres (bins). Nessa modelagem, os contêineres representam os servidores físicos, os itens são as VMs que devem ser alocadas, o tamanho de cada contêiner é a sua capacidade de CPU disponível e os custos são o consumo de energia causado pelos servidores. O sistema alvo consiste em servidores físicos heterogêneos e o SLA é definido por uma métrica de QoS independente de carga de trabalho. Em um trabalho mais

32 2.3 Eficiência energética 30 recente [11], Beloglazov et al. propuseram um modelo de cadeia de Markov que resolve o problema da detecção de sobrecarga de servidores. Verma et al. [74] definiram o problema da alocação de VMs ciente do consumo de energia como um problema de otimização contínua. Periodicamente, VMs em execução são migradas de um servidor físico para outro, possivelmente com características de hardware diferentes, de forma que recursos possam ser liberados e colocados em estados de economia de energia. Os autores trataram o problema usando heurísticas para o problema bin-packing. No entanto, a solução proposta não suporta a definição de SLA e o algoritmo de consolidação de VM pode degradar o desempenho das aplicações. Kusic et al. [47] assumiram o problema da consolidação de VMs como um problema de otimização sequencial sob incerteza e o resolveram usando a técnica de predição Limited Lookahead Control. Nesse modelo, o SLA é definido como taxas de processamento de requisição. Os clientes pagam por serviços providos pela infraestrutura e são ressarcidos em caso de violação de SLA. O objetivo é maximizar os ganhos do provedor da infraestrutura, minimizando o consumo de energia e reduzindo o risco de violação de SLA. O modelo proposto também incorpora os custos devido à ativação e desativação dos servidores, bem como heterogeneidade do hardware. Esse modelo, no entanto, requer uma fase de treinamento para se ajustar às características específicas das aplicações do usuário, limitando, dessa forma, a generalização da abordagem. A limitação comum dos trabalhos discutidos [10, 11, 47, 57, 74] está no fato de que suas soluções para consolidação de VMs focam apenas em CPU como fonte de consumo de energia. No entanto, como mencionado anteriormente, estima-se que a RAM seja responsável por cerca de 25% a 40% do consumo total de energia de um servidor. De fato, outros trabalhos têm tratado o problema da consolidação de VMs ciente do consumo de energia considerando mais do que o uso de CPU como dimensão. Por exemplo, Feller et al. [28] propuseram um arcabouço de gerenciamento de VMs que considera CPU, memória e rede como fontes do consumo de energia. Para cada recurso, os autores aplicam limiares estáticos de utilização para determinar se o recurso está sobrecarregado ou subutilizado, e o problema de alocação de VMs é tratado como uma variante do problema bin-packing multidimensional. Os autores implementaram e avaliaram os algoritmos propostos em um ambiente real usando a plataforma de experimentação Grid No entanto, os limiares estáticos de utilização não são compatíveis com ambientes IaaS com cargas de trabalho dinâmicas e imprevisíveis [10, 11]. Outra limitação do trabalho de Feller et al. é o modelo do sistema, que assume um ambiente homogêneo enquanto heterogeneidade prevalece em centros de dados para computação em nuvem Uma abordagem diferente foi adotada por Zhang et al. [83]. Os autores propuseram um sistema de gerenciamento de recursos multidimensional ciente de heterogeneidade para ambiente de computação em nuvem no qual o problema da consolidação de VM

33 2.3 Eficiência energética 31 é dividido em duas partes principais. Primeiro, o sistema classifica a carga em classes de tarefas de acordo com características tais como prioridade, CPU, tamanho de memória e tempo de execução. A classificação é implementada usando o algoritmo de agrupamento K-means. Por fim, o sistema usa essa informação para estimar o número mínimo de VMs requeridas para suportar a carga de trabalho para o próximo período de controle, bem como o número mínimo de servidores físicos para hospedar essas VMs. Um modelo de teoria de fila é utilizado para realizar essa estimativa. A formulação do problema também considera um modelo de energia multidimensional (CPU, memória, disco) onde o consumo total de energia de um servidor físico é estimado como uma função linear da utilização de recurso. No entanto, esse modelo não é realista para o consumo de RAM, uma vez que esse recurso frequentemente consome energia de uma maneira desproporcional à sua carga [20]. A Tabela 2.1 apresenta as características mais relevantes das soluções da literatura cujo foco se encontra em redução de consumo energético. Da análise dessas soluções, identificamos a ausência de uma solução que utilizasse um modelo energético para o uso de RAM, conjuntamente com um modelo para CPU, na consolidação de VMs. Tabela 2.1: Características da literatura revisada. Autores Recursos analisados Métodos utilizados Barroso et al. [7] CPU Desligamento de servidores ociosos Beloglazov et al. [9, 10, 11] CPU Consolidação de VMs, desligamento de servidores ociosos, DVFS Buyya et al. [14] CPU DVFS Cardosa et al. [16] CPU DVFS Chase et al. [17] CPU Desligamento de servidores ociosos Delaluz et al. [21] RAM DCD Diniz et al. [24] RAM DCD Elnozahy et al. [25] CPU Desligamento de servidores ociosos, DVFS Fan et al. [26] RAM DCD Feller et al. [28] CPU, RAM, rede Consolidação de VMs, desligamento de servidores ociosos, limiares de utilização Gandhi et al. [32] CPU DVFS Garg et al. [33, 34] CPU Desligamento de servidores ociosos, DVFS Gmach et al. [35] CPU, RAM Consolidação de VMs, desligamento de servidores ociosos Graubner et al. [40] CPU, RAM, disco Consolidação de VMs, desligamento Continua na próxima página

34 2.4 Conclusão 32 Tabela 2.1 Características da literatura revisada (continuação). Autores Recursos analisados Métodos utilizados de servidores ociosos, limiares de utilização Huang et al. [43] RAM DCD Kim et al. [46] CPU DVFS Kusic et al. [47] CPU Consolidação de VMs, desligamento de servidores ociosos, DVFS Lebeck et al. [49] RAM DCD Li et al. [51] RAM DCD Nathuji et al. [57, 56] CPU Consolidação de VMs, desligamento de servidores ociosos, DVFS Pandey et al. [59] RAM DCD Pinheiro et al. [65] CPU Desligamento de servidores ociosos Raghavendra et al. [67] CPU Consolidação de VMs, desligamento de servidores ociosos, DVFS Srikantaiah et al. [72] CPU, disco Consolidação de carga de trabalho, desligamento de servidores ociosos, DVFS Verma et al. [74] CPU Consolidação de VMs, desligamento de servidores ociosos, DVFS Zhang et al. [83] CPU, RAM, disco Consolidação de VMs, classificação de carga de trabalho 2.4 Conclusão Neste capítulo, foram abordados os principais conceitos a respeito de computação em nuvem, bem como algumas técnicas relevantes que têm como objetivo alcançar eficiência energética em centros de dados em nuvem. Essas técnicas foram classificadas em três grupos, tomando como base o nível em que atuam, a saber, centro de dados, hardware e software. O desligamento de servidores inativos, a desativação dinâmica de componentes, a variação de tensão de alimentação e frequência de relógio proporcional à utilização do recurso computacional e virtualização também foram brevemente abordados, pois são elementos importantes neste trabalho. No capítulo seguinte, será apresentado o modelo do sistema utilizado neste trabalho. Além disso, serão apresentados também os modelos utilizados para quantificar

35 2.4 Conclusão 33 o consumo de energia requerido por uso de CPU e RAM. Por fim, serão apresentadas as propostas para consolidação de VMs com foco no compromisso entre em eficiência energética e manutenção da qualidade de serviço.

36 Modelos e propostas CAPÍTULO 3 Neste capítulo, são descritos o modelo do sistema e os modelos de energia utilizados para quantificar o consumo de CPU e RAM. Além disso, são descritos os mecanismos propostos para consolidação de VMs com foco em eficiência energética e manutenção de SLA de centros de dados para computação em nuvem. 3.1 Modelo do sistema Neste trabalho, usamos simulação para modelar um ambiente no qual a infraestrutura é fornecida como um serviço (IaaS), representada por um extenso centro de dados com centenas de servidores físicos. A escolha do ambiente em IaaS se justifica pelo fato de que o foco deste trabalho está na gerência dos recursos computacionais, sob os aspectos de utilização de hardware e virtualização. Os servidores possuem hardware heterogêneo, i.e., há diferentes velocidades de CPU, tamanhos de memória e demanda por consumo energético. As VMs executadas nestes servidores também podem ter demandas heterogêneas por QoS, i.e., cada VM pode gerar diferentes cargas de CPU, uso de memória e uso da rede. Os servidores apenas mantêm disco local para carga do sistema operacional e o armazenamento de VMs, enquanto os dados são mantidos por um equipamento especializado em armazenamento que está conectado aos servidores através de uma rede de alta velocidade Network Attached Storage (NAS). Diversos tipos de usuários e aplicações podem usar o sistema de computação na nuvem e nenhum conhecimento prévio da carga de trabalho é necessário. Os usuários e o provedor IaaS negociam os requisitos de QoS em termos de SLA. Por exemplo, um SLA pode definir como requisito uma vazão mínima da rede ou um tempo de resposta máximo para uma aplicação. Se os requisitos não são completamente satisfeitos, há uma violação de SLA. A violação de SLA implica em reembolso do provedor IaaS para o usuário. Embora não seja descrito aqui como esse reembolso é pago, a violação de SLA é mensurada de forma que a perda potencial do provedor IaaS possa ser quantificada.

37 3.2 Modelo de energia 35 De maneira similar a Nathuji e Schwan [57], este trabalho assume um sistema compreendendo duas camadas de software: um gerente global e múltiplos gerentes locais. Cada gerente local se encontra em um servidor físico e é responsável por monitorar a utilização de CPU e RAM. Sendo executado como um módulo do VMM, o gerente local também decide quando e quais VMs precisam ser migradas do servidor. Além disso, ele é responsável também por alterar o modo de energia do servidor: desligá-lo ou colocá-lo em estado de dormência. Periodicamente, o gerente global coleta informações dos gerentes locais para decidir se a alocação de VM precisa ser alterada. Essa operação ocorre em tempo de execução através de migração ao vivo das VMs entre os servidores disponíveis. Além disso, é de responsabilidade do gerente global verificar se existe algum servidor subutilizado. A Figura 3.1 ilustra a arquitetura do sistema modelado. Figura 3.1: Arquitetura do sistema modelado. Nas seções seguintes, são descritos os modelos de energia utilizados para CPU e RAM. Em seguida, são apresentadas as propostas de mecanismos para consolidação de máquinas virtuais com foco no compromisso entre em eficiência energética e manutenção da qualidade de serviço. 3.2 Modelo de energia Neste trabalho, a energia consumida por um servidor físico (E Total ) é representada como a soma da energia consumida no uso de CPU (E CPU ) e de RAM (E RAM ), como mostrado na Equação 3-1. No entanto, essa suposição não é acurada, ainda que se trate de

38 3.2 Modelo de energia 36 uma melhoria em relação a outros trabalhos citados no Capítulo 2. Além disso, os outros dois principais componentes de hardware (disco e interface de rede) possuem contribuição limitada no cenário utilizado neste trabalho. O disco é pouco utilizado, uma vez que apenas o sistema operacional é armazenado localmente. Em operação, uma interface de rede de 10 Gbps consome aproximadamente 10% da energia de um servidor típico, enquanto uma interface de rede de 1 Gbps consome menos que 7%, de acordo com Sohan et al. [70]. E Total = E CPU + E RAM. (3-1) Modelo de energia de CPU De maneira similar a Beloglazov et al. [10], o consumo de energia pelo uso de CPU foi estimado através de dados reais para consumo de energia de servidores obtidos pelo benchmark SPECpower [71]. A Tabela 3.1 mostra o consumo de energia do sistema em função da utilização de CPU para os dois servidores utilizados neste trabalho: HP ProLiant ML110 G4 (Intel Xeon 3040, dual-core, 1860 MHz) e HP ProLiant ML110 G5 (Intel Xeon 3075, dual-core, 2660 MHz). Servidor 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% HP ProLiant G ,4 92, , HP ProLiant G5 93, Tabela 3.1: Consumo de energia, em Watts, em função do percentual de utilização de CPU Modelo de energia de RAM O consumo de energia pelo uso de RAM dos servidores foi estimado através da implementação de um modelo analítico derivado do trabalho de David et al. [20], no qual dois componentes são responsáveis pelo consumo de energia: 1. consumo de fundo (ou background), o qual não depende do tipo ou da quantidade de comandos executados pelo sistema, mas sim do estado de operação da memória, 2. consumo operacional, causado por operações de leitura ou escrita. Durante o desenvolvimento deste trabalho, dois modelos de consumo de energia por uso de RAM foram elaborados. O primeiro modelo proposto é mostrado na Equação 3-2. Nesse modelo, foi considerado que a memória sempre está no estado de prontidão ativo.

39 3.2 Modelo de energia 37 E RAM = E ActS b + ((E B,l LB l ) + (E B,e LB e )), (3-2) onde E ActS b representa o consumo de fundo, no estado de prontidão ativa; E B,l e E B,e são respectivamente a energia requerida para leitura e escrita por GB/s; e LB l e LB e indicam a largura de banda de leitura e escrita, respectivamente. Dada a pequena diferença de consumo entre as operações de leitura e escrita, assumimos que metade da largura de banda é usada para operações de leitura e metade para operações de escrita. Essa proposta, no entanto, se mostrou pouco acurada, uma vez que se baseia em suposições não realistas sobre a largura de banda da RAM. De acordo com essa proposta, toda a capacidade de RAM seria contabilizada como largura de banda. Essa suposição implicaria em uma arquitetura extremamente eficiente e não condizente com o estadoda-arte. Por exemplo, em um cenário típico, 32 GB de RAM indicaria uma largura de banda de 32 GB/s. Além disso, considerou-se que a RAM estaria sendo utilizada em sua capacidade máxima. Assim, não haveria qualquer relação entre a execução de aplicações em uma VM e a utilização de RAM. No segundo modelo proposto, foram utilizados os estados desligado ativo e de prontidão ativa. De prontidão ativa é o estado com o maior consumo de energia, porém, não possui nenhuma latência, como pode ser visto na Tabela 3.2, gerada a partir de dados disponíveis no trabalho de David et al. [20] e JEDEC [44]. Desligado ativo é um estado que consome aproximadamente 39% menos energia que o estado de prontidão ativa, e possui relativamente um custo moderado de latência. Nesse segundo modelo, assume-se que a RAM permanece no estado de prontidão ativa durante o tempo em que a CPU está sendo utilizada e comuta para o estado desligado ativo tão logo a CPU se torne ociosa. O consumo operacional é o produto da largura de banda de memória e a energia necessária para executar um comando específico, de leitura ou escrita, por unidade de largura de banda. Semelhante ao modelo anterior, como a diferença entre o consumo de energia por operação de leitura e de escrita é pequena, é assumido que elas ocorrem a uma mesma taxa. De maneira diferente do primeiro modelo, assumimos aqui que as operações de leitura/escrita na RAM acontecem durante quantidades aleatórias do tempo de utilização da CPU. Assim, estabelecemos uma relação entre a carga da VM, em termos de uso de CPU, com sua demanda por RAM. Essa abordagem foi utilizada devido à ausência de perfis de aplicações em nuvem disponíveis publicamente. Assim, o consumo de energia por RAM é descrito pela Equação 3-3:

40 3.3 Mecanismos propostos 38 E RAM = (CPU % E Act_Sb + (1 CPU % ) E Act_Pd ) + (RAM B (E B,l + E B,e ) 2 CPU % U(0,1)), (3-3) onde CPU % é a utilização de CPU, variando de 0 a 1. De acordo com David et al. [20], o consumo de fundo para cada 4 GB de RAM DDR3, operando a MHz, no estado de prontidão ativa é E Act_Sb = 5,36W, e no estado desligado ativo é E Act_Pd = 3,28W. Nós utilizamos RAM B = 10,7GB/s, pois esse é o valor de pico da taxa de transferência da RAM DDR3 a MHz. Ainda de acordo com David et al. [20], o consumo operacional da operação de leitura é E B,l = 0,939W/(GB/s), e da operação de escrita é E B,e = 1,023W/(GB/s). U(0,1) representa a escolha de um valor aleatório de uma distribuição uniforme. Esse valor descreve a quantidade de tempo de utilização da CPU que é gasta com operações de leitura e escrita envolvendo a RAM. Tabela 3.2: Consumo de energia, em Watts, e tempo de latência em função do modo de operação da RAM. A latência é medida, na maioria dos estados, em função do tempo de relógio (tck). Os valores da tabela se referem à arquitetura DDR MHz. Modo de operação Tempo estimado de latência Consumo de energia De prontidão ativa 0 5,36W De prontidão com pré-carga 10,5ns 4,66W Desligado ativo 3tCK 3,28W Desligado com pré-carga rápida 3tCK + 10,5ns 2,79W Desligado com pré-carga lenta 10tCK 1,60W Desligado com pré-carga lenta e registradores desligados 14tCK 1,35W Auto-atualizado 512tCK 0,92W Auto-atualizado com registradores desligados 512tCK + 6µs 0,56W 3.3 Mecanismos propostos Seguindo a abordagem proposta por Beloglazov et al. [10], o problema da consolidação de VMs ciente de consumo de energia é dividido em quatro subproblemas: 1. Decidir quando um servidor está sobrecarregado, o que gera a necessidade de migrar uma ou mais VMs para outros servidores; 2. Decidir quando um servidor está subutilizado, o que gera a necessidade de migrar todas as suas VMs para outro servidor e então desligá-lo ou colocá-lo em modo de dormência; 3. Selecionar VMs para serem migradas de um servidor sobrecarregado;

41 3.3 Mecanismos propostos Decidir uma nova alocação para as VMs que são selecionados para migração dos servidores sobrecarregados e subutilizados. A Figura 3.2 ilustra o processo de consolidação como um fluxo das verificações realizadas pelas heurísticas que tratam os subproblemas descritos acima. Figura 3.2: Etapas da consolidação de máquinas virtuais. A região delimitada à esquerda representa o conjunto de etapas nas quais os gerentes locais atuam (servidores), enquanto que a região delimitada à direita representa o conjunto de etapas nas quais o gerente global atua (centro de dados). Os componentes em vermelho representam os subproblemas para os quais este trabalho oferece contribuição. Este trabalho apresenta novas soluções para tratar os subproblemas 2, 3 e 4. Na seção seguinte, são apresentadas informações adicionais sobre cada subproblema, bem como uma descrição mais detalhada daqueles para os quais são apresentadas contribuições Detecção de servidores sobrecarregados Beloglazov et al. [10] propuseram e avaliaram quatro algoritmos para solução do problema da detecção de sobrecarga nos servidores: Median Absolute Deviation (MAD), Interquartile Range (IQR), Local Regression (LR) e Local Regression Robust (LRR). Os autores mostraram que o algoritmo LR provê os melhores resultados. Nos diversos experimentos realizados, observamos que o algoritmo IQR também alcança resultados promissores quando combinado com as propostas deste trabalho. No Capítulo 4, avaliamos esses dois algoritmos, tanto individualmente quanto em combinação com as soluções que propusemos. Tanto LR quanto IQR são algoritmos para configurar um limiar de utilização de CPU, i.e., eles monitoram a utilização de CPU do servidor e migram uma ou mais VMs se o limiar definido é excedido. Além disso, os algoritmos aplicam análise estatística para adaptar dinamicamente o limiar de utilização de CPU.