MARÍA ELENA VILLARREAL NETPOWERCLOUDSIM: EXTENSÃO DO CLOUDSIM PARA VALIDAÇÃO DE UM MODELO DE GERENCIAMENTO DE EQUIPAMENTOS DE REDE LEGADOS EM NUVEM VERDE Rio do Sul 2013 MARÍA ELENA VILLARREAL NETPOWERCLOUDSIM: EXTENSÃO DO CLOUDSIM PARA VALIDAÇÃO DE UM MODELO DE GERENCIAMENTO DE EQUIPAMENTOS DE REDE LEGADOS EM NUVEM VERDE Trabalho de Curso apresentado ao curso de graduação em Ciência da Computação do Instituto Federal de Educação, Ciência e Tecnologia Catarinense – Campus Rio do Sul para a obtenção do título de Bacharel em Ciência da Computação. Orientador: Prof. Rodrigo Curvêllo, Msc Rio do Sul 2013 MARÍA ELENA VILLARREAL NETPOWERCLOUDSIM: EXTENSÃO DO CLOUDSIM PARA VALIDAÇÃO DE UM MODELO DE GERENCIAMENTO DE EQUIPAMENTOS DE REDE LEGADOS EM NUVEM VERDE Este Trabalho de Curso foi julgado adequado para a obtenção do título de Bacharel em Ciência da Computação e aprovado em sua forma final pelo curso de Ciência da Computação do Instituto Federal de Educação, Ciência e Tecnologia Catarinense – Campus Rio do Sul. _________________________, ______de_______________de 20_____. _________________________________________________ Prof. Rodrigo Curvêllo, Msc (Orientador) Instituto Federal Catarinense – Campus Rio do Sul _________________________________________________ Prof. Tiago Boechel, Msc Instituto Federal Catarinense – Campus Rio do Sul _________________________________________________ Prof. Paulo César Rodacki Gomes, Dr Instituto Federal Catarinense – Campus Blumenau AGRADECIMENTOS A Deus. À minha família pelo apoio e incentivo. Ao meu orientador , Rodrigo Curvêllo, pelo auxílio no desenvolvimento deste trabalho. RESUMO A Computação em Nuvem é um paradigma que fornece infraestrutura, plataforma de desenvolvimento e aplicativos como serviço, sob demanda e cobrados conforme a medição de uso. Na prática, a Nuvem é implementada em datacenters, onde se concentram servidores físicos que executam máquinas virtuais através das quais são prestados os serviços de computação. A abordagem de Nuvem Verde incrementa o modelo com a proposta de reduzir o consumo elétrico sem prejudicar a qualidade de serviço, mediante a concentração da carga de trabalho na menor quantidade possível de equipamentos e desligando ou colocando em estado de baixo consumo de energia os equipamentos ociosos. Simuladores são utilizados para validar os algoritmos e estratégias de gerenciamento de nuvem verde. Este trabalho teve como principal objetivo estender o CloudSim, um simulador de código aberto de ambientes computacionais em nuvem, para que suporte a realização dos testes necessários para a validação de um modelo de gerenciamento de equipamentos de rede legados em nuvem verde. A metodologia utilizada consistiu em pesquisa bibliográfica, levantamento dos requisitos funcionais e não funcionais, projeto e implementação das extensões em linguagem Java e validação mediante testes e experimentos. Foram desenvolvidas classes que incorporam ao CloudSim a capacidade de representar os equipamentos da rede e a sua topologia e uma classe para gerenciá-los conforme as mudanças de estado dos servidores físicos. As extensões foram validadas através de testes e da comparação dos resultados de simulações em diferentes cenários, que demonstraram seu correto funcionamento. Palavras-chave: Computação em Nuvem. Nuvem Verde. Simulação. CloudSim. Datacenter. Gerenciamento de rede. LISTA DE FIGURAS Figura 1 – Camadas da implementação de uma nuvem. ......................................................... 19 Figura 2 – Arquitetura de nuvem verde e seus componentes. ................................................. 20 Figura 3 – Políticas de alocação: (a) Espaço compartilhado para MVs e tarefas, (b) Espaço compartilhado para MVs e tempo compartilhado para tarefas, (c) Tempo compartilhado para MVs e espaço compartilhado para tarefas, (d) Tempo compartilhado para MVs e tarefas. .... 27 Figura 4 – Diagrama de sequência do processamento de aplicações. ..................................... 29 Figura 5 – Diagrama de sequência da comunicação entre entidades. ..................................... 30 Figura 6 – Arquitetura de camadas do CloudSim. .................................................................. 31 Figura 7 – Diagrama de classes UML do CloudSim. .............................................................. 34 Figura 8 – Diagrama de classes UML do núcleo do CloudSim. ............................................. 35 Figura 9 – Topologia de rede padrão de um datacenter. ......................................................... 37 Figura 10 – Diagrama de casos de uso da interação do usuário com o simulador. ................. 42 Figura 11 – Diagrama de casos de uso da interação da interação do CloudSim com as extensões................................................................................................................................... 43 Figura 12 – Diagrama de classes do NetPowerCloudSim. ...................................................... 44 Figura 13 – Diagrama de sequência da aplicação principal. ................................................... 45 Figura 14 – Diagrama de atividades do processo de reconfiguração da rede. ........................ 46 Figura 15 – Tela principal do NetPowerCloudSim. ................................................................ 54 Figura 16 – Resultados dos testes de unidade da classe TopologiaRede. ............................... 56 Figura 17 – Gráfico da evolução do consumo da rede no Experimento 2. ............................. 60 Figura 18 – Gráfico da evolução do consumo da rede no Experimento 3. ............................. 62 LISTA DE QUADROS Quadro 1 – Requisitos funcionais. .......................................................................................... 41 Quadro 2 – Requisitos não funcionais..................................................................................... 41 Quadro 3 – Código do método que calcula a energia consumida por um switch durante um frame da simulação. .................................................................................................................. 48 Quadro 4 – Trecho de código para atualizar o consumo atual do switch................................ 49 Quadro 5 – Trecho de código do método verificaMudancaEstadoHost. ................................ 50 Quadro 6 – Trecho do método que calcula as quantidades de racks, de switches de acesso, de switches de agregação, de switches de núcleo e de módulos por switch de núcleo. ................ 51 Quadro 7 – Código do método que calcula os ids dos switches de acesso e o número das portas aos quais uma máquina física está conectada. ............................................................... 52 Quadro 8 – Trecho de código do método desligaPortasSemUso que desliga as portas sem uso dos dois últimos switches de acesso. ........................................................................................ 52 Quadro 9 – Código gerado pelo JUnit para teste do método calculaSwitchAcessoEporta e adaptado com id de máquina física e resultados esperados. ..................................................... 55 Quadro 10 – Resultados do Experimento 1. ............................................................................ 58 Quadro 11 – Resultados do Experimento 2. ............................................................................ 59 Quadro 12 – Resultados do Experimento 3. ............................................................................ 61 Quadro 13 – Detalhamento do caso de uso UC01. ................................................................. 68 Quadro 14 – Detalhamento do caso de uso UC02. ................................................................. 68 Quadro 15 – Detalhamento do caso de uso UC03. ................................................................. 69 Quadro 16 – Detalhamento do caso de uso UC04. ................................................................. 70 Quadro 17 – Detalhamento do caso de uso UC05. ................................................................. 70 Quadro 18 – Detalhamento do caso de uso UC06. ................................................................. 71 Quadro 19 – Detalhamento do caso de uso UC07. ................................................................. 71 Quadro 20 – Detalhamento do caso de uso UC08. ................................................................. 72 Quadro 21 – Detalhamento do caso de uso UC09. ................................................................. 72 Quadro 22 – Detalhamento do caso de uso UC10. ................................................................. 73 Quadro 23 – Detalhamento do caso de uso UC11. ................................................................. 74 Quadro 24 – Detalhamento do caso de uso UC12. ................................................................. 75 Quadro 25 – Detalhamento do caso de uso UC13. ................................................................. 76 Quadro 26 – Detalhamento do caso de uso UC14. ................................................................. 76 LISTA DE SIGLAS BRITE – Boston university Representative Internet Topology gEnerator CIS – Cloud Information Service CM – Cloud Manager CPU – Central Processing Unit EC2 – Elastic Compute Cloud IaaS – Infrastructure as a Service LAN – Local Access Network MF – Máquina Física MV – Máquina Virtual NIST – National Institute of Standards and Technology OTM – Organization Theory Model PaaS – Platform as a Service PE – Processing Element QoS – Quality of Service RAM – Random Access Memory SaaS – Software as a Service SLA – Service Level Agreement UML – Unified Modeling Language VIM – Virtual Infrastructure Manager VMM – Virtual Machine Manager SUMÁRIO 1 INTRODUÇÃO ................................................................................................................... 10 1.1 PROBLEMA ...................................................................................................................... 11 1.2 OBJETIVOS ....................................................................................................................... 12 1.2.1 Objetivo Geral................................................................................................................ 12 1.2.2 Objetivos Específicos ..................................................................................................... 12 1.3 JUSTIFICATIVA ............................................................................................................... 12 1.4 METODOLOGIA ............................................................................................................... 13 2 FUNDAMENTAÇÃO TEÓRICA ...................................................................................... 14 2.1 COMPUTAÇÃO EM NUVEM.......................................................................................... 14 2.1.1 Características da abordagem de nuvem .................................................................... 15 2.1.2 Modelos de serviços ....................................................................................................... 16 2.1.3 Modelos de implantação ................................................................................................ 17 2.1.4 Implementação de uma nuvem ..................................................................................... 17 2.1.5 Computação em Nuvem Verde ..................................................................................... 19 2.2 SIMULAÇÃO .................................................................................................................... 21 2.2.1 Conceitos relacionados .................................................................................................. 21 2.2.2 Vantagens e desvantagens ............................................................................................. 23 2.3 CLOUDSIM ....................................................................................................................... 25 2.3.1 Funcionamento do CloudSim ....................................................................................... 26 2.3.1.1 Modelagem da nuvem .................................................................................................. 26 2.3.1.2 Modelagem da alocação de máquinas virtuais ............................................................. 27 2.3.1.3 Modelagem do comportamento da rede ....................................................................... 27 2.3.1.4 Modelagem de cargas de trabalho dinâmicas ............................................................... 28 2.3.1.5 Modelagem do consumo de energia do datacenter ...................................................... 28 2.3.1.7 Processamento interno do datacenter ........................................................................... 29 2.3.1.8 Comunicação entre entidades ....................................................................................... 29 2.3.2 Arquitetura do CloudSim ............................................................................................. 30 2.3.3 Estrutura do CloudSim ................................................................................................. 31 2.4 TRABALHOS CORRELATOS ......................................................................................... 36 2.4.1 Modelos de Gerenciamento de Nuvem Verde ............................................................. 36 2.4.2 TeachCloud .................................................................................................................... 38 2.4.3 CloudReports ................................................................................................................. 38 2.4.4 NetworkCloudSim ......................................................................................................... 39 3 DESENVOLVIMENTO ...................................................................................................... 40 3.1 DESCRIÇÃO...................................................................................................................... 40 3.2 REQUISITOS ..................................................................................................................... 40 3.3 ESPECIFICAÇÃO ............................................................................................................. 41 3.3.1 Casos de Uso ................................................................................................................... 42 3.3.2 Diagrama de Classes ...................................................................................................... 44 3.3.3 Diagrama de Sequência ................................................................................................. 45 3.3.4 Diagrama de Atividades ................................................................................................ 45 3.4 IMPLEMENTAÇÃO.......................................................................................................... 47 3.4.1 Técnicas e ferramentas .................................................................................................. 47 3.4.2 Codificação das extensões ............................................................................................. 47 3.4.2.1 PowerSwitch ................................................................................................................. 48 3.4.2.2 NetPowerDatacenter ..................................................................................................... 49 3.4.2.3 TopologiaRede.............................................................................................................. 50 3.4.2.4 GerenciadorRede .......................................................................................................... 52 3.4.2.5 Classe principal e interface gráfica ............................................................................... 53 3.5 TESTES .............................................................................................................................. 54 3.5.1 Testes de Unidade .......................................................................................................... 54 3.5.2 Testes de Integração ...................................................................................................... 56 3.5.3 Validação de requisitos ................................................................................................. 57 3.6 SIMULAÇÕES E RESULTADOS .................................................................................... 57 3.6.1 Experimento 1 ................................................................................................................ 57 3.6.2 Experimento 2 ................................................................................................................ 58 3.6.3 Experimento 3 ................................................................................................................ 60 4 CONCLUSÕES .................................................................................................................... 63 REFERÊNCIAS...................................................................................................................... 65 APÊNDICE A – Detalhamento dos Casos de Uso ............................................................... 68 10 1 INTRODUÇÃO Com a crescente preocupação por sustentabilidade e, consequentemente, pelo consumo consciente de energia, o conceito de Green Cloud, ou Nuvem Verde, tem ganhado destaque na comunidade científica. Esta abordagem une os conceitos de Computação em Nuvem (Cloud Computing) e TI Verde (Green IT) com o intuito de “oferecer um ambiente computacional flexível e eficiente” (WESTPHALL, VILLARREAL, 2013, p. 1). De acordo com Geronimo (2012), o modelo de computação em nuvem verde visa, além da economia de consumo energético, a redução de custos operacionais e o prolongamento da vida útil de equipamentos em ambientes computacionais em nuvem. Refere-se, portanto, à “utilização consciente e sustentável da tecnologia de Cloud Computing” (GERONIMO, 2012, p. 39). Esta, por sua vez, pode ser definida como uma categoria de serviços computacionais sofisticados oferecidos sob demanda através da Internet em que a infraestrutura computacional é vista como uma “nuvem” e cujo princípio central é prover computação, armazenamento e software “as a service” 1 (VOORSLUYS; BROBERG; BUYYA, 2011, p. 3). Na prática, segundo Westphall e Villarreal (2013), a nuvem é implementada em datacenters, que concentram grande quantidade de máquinas físicas sobre as quais são executadas as máquinas virtuais que são fornecidas aos clientes. Na computação em nuvem verde, utiliza-se o conceito de consolidação de carga, que consiste em alocar a carga de trabalho na menor quantidade possível de máquinas físicas para permitir desligar os recursos ociosos ou colocá-los em estado de baixo consumo de energia elétrica (WESTPHALL; VILLARREAL, 2013). No entanto, segundo Villarreal e Westphall (2013), as estratégias de gerenciamento de Nuvem Verde não têm dado suficiente atenção ao consumo dos equipamentos de rede e à consolidação do tráfego e propuseram um modelo para o gerenciamento dos recursos de rede dos datacenters, tanto os legados quanto os de tecnologia verde. Segundo Calheiros et al. (2011), diversos tipos de serviços podem ser oferecidos em ambientes computacionais em nuvem e cada um possui diferentes exigências de composição, configuração e implantação. Assim, a realização de testes em ambientes reais para avaliar o desempenho destes serviços sob condições variáveis, frequentemente, não é uma tarefa viável, visto que demanda muito tempo e é limitada pela rigidez física da estrutura. 1 Tradução: como um serviço. 11 As ferramentas de simulação, por outro lado, facilitam a reprodução de resultados ao permitirem testar distintos cenários em ambientes repetíveis e controláveis antes da implantação dos serviços em infraestruturas reais (CALHEIROS et al., 2011). O CloudSim é um framework 2 que permite modelar e simular ambientes computacionais em nuvem. De acordo com Calheiros et al. (2011), este conjunto de ferramentas foi desenvolvido na linguagem de programação Java e suporta a simulação de componentes de ambientes em nuvem como datacenters, máquinas virtuais e políticas de provisionamento de recursos. O simulador permite ainda que seus recursos sejam estendidos, o que possibilita a modelagem de ambientes de computação em nuvem personalizados e a realização de testes baseados em cenários e configurações específicos para atender a uma determinada pesquisa (CALHEIROS et al., 2011). Neste trabalho, são realizadas extensões ao simulador CloudSim para permitir a validação do modelo de gerenciamento de equipamentos de redes citado anteriormente. Nas seções seguintes são descritos o problema, os objetivos, a justificativa e a metodologia. No capítulo 2, é apresentada a fundamentação teórica, que aborda os conceitos de Computação em Nuvem e Nuvem Verde, o processo de simulação, a estrutura e o funcionamento do CloudSim e os trabalhos correlatos. No capítulo 3, é relatado o desenvolvimento das extensões, incluindo os requisitos funcionais e não funcionais; a especificação da implementação; os testes realizados; as simulações executadas e os resultados obtidos. Por fim, no capítulo 4, são feitas as considerações finais e propostas de trabalhos futuros. 1.1 PROBLEMA Villarreal e Westphall (2013) propuseram uma ampliação a uma abordagem de alocação e distribuição de máquinas virtuais em ambiente de nuvem computacional verde. Esta abordagem, baseada no modelo de Teoria da Organização, foi desenvolvida pelo Laboratório de Redes e Gerência (LRG) da Universidade Federal de Santa Catarina e apresentada e validada por Werner (2011). A extensão proposta incorpora estratégias de eficiência energética ao modelo mediante o acréscimo de mecanismos para o gerenciamento de recursos de rede de datacenters, tanto os legados quanto os de tecnologia verde (VILLARREAL; WESTPHALL, 2013). 2 Aplicação parcialmente completa e reutilizável que pode ser adaptada para o desenvolvimento de aplicações personalizadas (FAYAD; SCHMIDT, 1997). 12 No entanto, para medir os ganhos de eficiência obtidos com a otimização do consumo dos equipamentos de rede e validar o modelo ampliado, é necessário estender o simulador CloudSim, que não possui capacidade para representar os equipamentos e a topologia da rede e realizar seu gerenciamento, recursos necessários para os testes que devem ser realizados a fim de verificar os efeitos do modelo proposto. 1.2 OBJETIVOS 1.2.1 Objetivo Geral Este trabalho tem como objetivo estender o simulador CloudSim de forma que permita a realização dos testes necessários para a validação de um modelo de gerenciamento de equipamentos de rede legados em um ambiente computacional de nuvem verde. 1.2.2 Objetivos Específicos Os objetivos específicos do trabalho são: a) implementar classes para a representação de entidades de rede conforme as necessidades do modelo e para a geração da topologia da rede a partir de regras previamente definidas; b) incluir as funcionalidades de ativação e desativação de equipamentos de rede e portas em função da consolidação de carga dos servidores; c) permitir a configuração da velocidade das portas dos equipamentos de rede de acordo com as regras e crenças do modelo; d) calcular o consumo de energia dos equipamentos de rede e da rede em geral; e) interagir com as classes já existentes no simulador; f) integrar os resultados aos das classes do CloudSim. 1.3 JUSTIFICATIVA Através do gerenciamento dos recursos de rede em ambientes de nuvem computacional verde proposta por Villarreal e Westphall (2013), é possível diminuir o consumo energético de equipamentos de rede e servidores e, por conseguinte, obter significativos ganhos de eficiência em datacenters e reduzir o impacto ambiental. Para 13 mensurar e validar estes ganhos a fim de possibilitar a implantação do modelo em ambientes reais, é necessário realizar simulações que permitam testar os efeitos da aplicação desta abordagem “em diferentes cenários com diferentes exigências de desempenho e com diferentes regras e crenças” (VILLARREAL; WESTPHALL, 2013, p. 11). Estender o simulador CloudSim permitirá, além da validação do modelo mencionado, a realização de simulações para oferecer suporte a pesquisas da área de computação em nuvem verde realizadas pelo Laboratório de Redes e Gerência do departamento de Ciência da Computação da Universidade Federal de Santa Catarina. Além das contribuições ambientais e acadêmicas já citadas, as extensões realizadas ao CloudSim em conjunto com sua devida documentação podem servir como base para novas extensões, bem como para a criação de ferramentas completas de simulação específicas para ambientes computacionais em nuvem verde. 1.4 METODOLOGIA Para a elaboração deste trabalho, será realizada uma pesquisa bibliográfica em livros, artigos científicos publicados e monografias acadêmicas acerca dos temas de Computação em Nuvem e Computação em Nuvem Verde, bem como sobre os conceitos básicos de simulação. Também serão estudados e descritos a estrutura e o funcionamento do simulador CloudSim e trabalhos correlatos. Serão definidos os requisitos funcionais e não funcionais que devem ser atendidos pelas extensões e as classes a serem implementadas ou estendidas serão modeladas através de Diagramas UML de Classes, de Casos de Uso, de Atividades e de Sequência. Visto que o simulador CloudSim foi desenvolvido em Java, as extensões serão implementadas nesta linguagem e o paradigma de programação a ser utilizado é a orientação a objetos. Com o intuito de validar as extensões realizadas ao CloudSim, serão efetuados testes e experimentos de acordo com as regras e crenças definidas no modelo de simulação da abordagem proposta por Villarreal e Westphall (2013). Uma vez verificado e comprovado o correto funcionamento das extensões realizadas, estas serão documentadas com o auxílio do gerador de documentação Javadoc, desenvolvido pela Sun Microsystems. 14 2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo, é abordado o tema de Computação em Nuvem, através da definição do paradigma e da descrição de suas características fundamentais, dos tipos de serviços oferecidos e das formas de implantação. São descritas ainda a arquitetura e a implementação de uma nuvem. Em relação ao processo de simulação, são definidos conceitos básicos e relacionados, bem como seus aspectos positivos e negativos. Para o entendimento do funcionamento e da estrutura do simulador CloudSim, são apresentadas suas características e arquitetura, as principais classes de sua implementação e a forma como se relacionam. 2.1 COMPUTAÇÃO EM NUVEM A Computação em Nuvem, do inglês Cloud Computing, apresenta diversas definições na literatura. Com o intuito de conceituar o paradigma, duas delas são apresentadas a seguir: “Computação em nuvem é um modelo que permite acesso ubíquo, conveniente e sob demanda através de uma rede a um conjunto compartilhado de recursos computacionais configuráveis (como redes, servidores, armazenamento, aplicações e serviços) que podem ser rapidamente provisionados e liberados com um esforço mínimo de gestão ou de interação com o provedor de serviço” (MELL; GRANCE, 3 2011, p.2) . “Uma nuvem é um tipo de sistema de computação paralelo e distribuído que consiste em uma coleção de computadores virtualizados e interconectados que são provisionados dinamicamente e apresentados como um ou mais recursos computacionais unificados baseado em acordos de nível de serviço estabelecidos através de negociação entre o provedor de serviços e o consumidor” (BUYYA; 4 YEO; VENUGOPAL, 2008, p. 2) . Com base nestas definições, observa-se que a Computação em Nuvem abrange tanto as aplicações que são fornecidas como serviço através da Internet quanto o hardware e o software dos datacenters responsáveis pelo fornecimento de tais serviços (ARMBRUST et al., 2010). 3 Texto original traduzido por esta autora: “Cloud computing is a model for enabling ubiquitous, convenient, ondemand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction”. 4 Texto original traduzido por esta autora: "A Cloud is a type of parallel and distributed system consisting of a collection of inter-connected and virtualised computers that are dynamically provisioned and presented as one or more unified computing resources based on service-level agreements established through negotiation between the service provider and consumers”. 15 Em relação à origem do conceito, a Computação em nuvem é resultado da evolução e integração de diferentes tecnologias, como computação em grade, processamento paralelo, computação autônoma, virtualização e browsers. Já o termo surgiu em 2006 em uma palestra sobre como era realizado o gerenciamento dos datacenters da Google, ministrada pelo funcionário da empresa, Eric Schmidt, e ganhou maior destaque com o lançamento do serviço EC2 (Elastic Cloud Computing) da Amazon no mesmo ano (TAURION, 2009). 2.1.1 Características da abordagem de nuvem O NIST (National Institute of Standards and Technology) define cinco características essenciais que devem ser contempladas por uma nuvem (MELL; GRANCE, 2011). São elas: autoatendimento sob demanda: uma nuvem permite que seus usuários utilizem seus serviços de forma automática e sob demanda, sem a necessidade de interação com operadores humanos; amplo acesso à rede: os recursos são fornecidos através da rede e acessados por mecanismos padronizados, que permitem o uso por plataformas heterogêneas; agrupamento de recursos: os recursos computacionais (físicos e virtuais) do provedor de serviços são agrupados de forma a atender dinamicamente as demandas dos consumidores, que, na maior parte das vezes, não têm conhecimento da localização exata de tais recursos, mas podem ser capazes de determiná-la em um nível de abstração mais alto (como país, estado ou datacenter); rápida elasticidade: os recursos fornecidos através de uma nuvem podem ser provisionados e liberados rapidamente para ajustarem-se à variação da demanda. Como resultado, frequentemente, o usuário tem a impressão de que os recursos oferecidos são ilimitados; serviço medido: sistemas em nuvem controlam e otimizam o uso dos recursos automaticamente através de medições e podem monitorar e reportar a utilização de recursos de forma transparente aos consumidores e provedores. Para que uma nuvem atenda às expectativas dos consumidores, Voorsluys, Broberg e Buyya (2011) definem ainda como atributos indispensáveis: 16 medição e cobrança por uso: os recursos oferecidos por uma nuvem devem ser medidos de acordo com o tipo de serviço e cobrados conforme o uso; customização: como há grandes disparidades entre as necessidades dos usuários, os serviços da nuvem devem ser altamente personalizáveis. 2.1.2 Modelos de serviços Os serviços oferecidos em um ambiente computacional em nuvem são divididos em três modelos ou níveis de abstração, que podem ser vistos como uma arquitetura de camadas na qual os serviços de uma camada mais baixa compõem serviços de uma camada mais alta (VOORSLUYS; BROBERG; BUYYA, 2011). Os modelos de serviços são descritos a seguir: Infraestrutura como Serviço (IaaS – Infrastructure as a Service): de acordo com Voorsluys, Broberg e Buyya (2011), é considerada a camada inferior dos sistemas computacionais em nuvem e oferece recursos virtualizados de servidores de computação, armazenamento e comunicação sob demanda. Como exemplo deste modelo de serviço, pode-se citar o EC2 da Amazon Web Services, que permite aos usuários utilizar servidores virtuais e configurar e escalonar a capacidade do ambiente computacional (AMAZON, 2013); Plataforma como Serviço (PaaS – Platform as a Service): esta camada, com nível de abstração intermediário, oferece um ambiente de desenvolvimento e hospedagem que permite aos usuários criar aplicações sem preocupar-se com requisitos de infraestrutura, como quantidade de processadores ou memória necessários (VOORSLUYS; BROBERG; BUYYA, 2011). É exemplo deste tipo de serviço o Windows Azure, da Microsoft, que possibilita criar, implantar e gerenciar aplicativos através de uma rede global de datacenters (MICROSOFT, 2013); Software como Serviço (SaaS – Software as a Service): é a camada superior da arquitetura, na qual os serviços oferecidos consistem em aplicações que podem ser acessadas pelos usuários finais através da Web, sem a necessidade de instalá-las localmente e com as mesmas funcionalidades de programas tradicionais para desktop (VOORSLUYS; BROBERG; BUYYA, 2011). Assim, de acordo com Mell e Grance (2011, 17 p. 2), o serviço fornecido ao consumidor é o uso de aplicações do provedor que executam em uma infraestrutura de nuvem. O Google Apps constitui um exemplo deste modelo, uma vez que oferece como serviço aplicativos de e-mail, agenda, criação e compartilhamento de documentos, entre outros (GOOGLE, 2013). 2.1.3 Modelos de implantação Com base nas formas de implantação e acesso, e a despeito do modelo de serviço oferecido, uma nuvem pode ser classificada como: pública: modelo de nuvem disponibilizado por organizações empresariais, acadêmicas ou governamentais para o público em geral (MELL; GRANCE, 2011). De acordo com Sun Microsystems (2009), este tipo de nuvem permite que empresas utilizem infraestruturas muito maiores do que as que poderiam possuir e transfere os riscos destas para o provedor de serviços; privada: neste modelo, a infraestrutura da nuvem pode ser utilizada apenas por membros de uma determinada organização. No entanto, pode ser gerenciada pela própria organização ou por terceiros (MELL; GRANCE, 2011); comunitária: é compartilhada por um grupo de consumidores de organizações distintas, mas com objetivos ou políticas em comum e pode ser gerenciada e operada por uma ou mais organizações pertencentes à comunidade ou por terceiros (MELL; GRANCE, 2011); híbrida: uma nuvem híbrida, segundo Mell e Grance (2011), é composta por dois ou mais tipos diferentes de nuvens (pública, privada ou comunitária), que, apesar de unidas por tecnologias proprietárias ou padronizadas, permanecem como entidades únicas. 2.1.4 Implementação de uma nuvem De acordo com Taurion (2009, p.44), “o fundamento básico da Computação em Nuvem é a virtualização dos recursos computacionais” e, para que esta virtualização seja 18 possível, são empregadas distintas tecnologias, que formam uma estrutura de camadas. Esta estrutura e seus componentes são mostrados na Figura 1. A camada mais baixa compreende as Máquinas Físicas (MFs), que compõem o datacenter e consistem em servidores de computação e armazenamento que fornecem a infraestrutura de hardware para criar recursos virtualizados (BUYYA; BELOGLAZOV; ABAWAJY, 2010). A segunda camada contém o software de virtualização, denominado VMM (Virtual Machine Manager), que executa em cada servidor físico e tem como função instanciar as Máquinas Virtuais (MVs) que são fornecidas aos consumidores (CELESTI et al., 2013). Segundo Chaves, Uriarte e Westphall (2011) o VMM, também chamado de monitor, permite executar o sistema operacional hóspede em cada máquina virtual e fornece a interface entre os recursos virtuais e reais do sistema hospedeiro. Na terceira camada, encontra-se o VIM (Virtual Infrastructure Manager), cuja finalidade é o gerenciamento de recursos físicos e virtuais. Este middleware define quais MVs serão instanciadas e em qual servidor físico e é responsável por configurá-las (CELESTI et al., 2013). Voorsluys, Broberg e Buyya (2011) comparam o VIM a um sistema operacional tradicional, com a diferença de que este agrega recursos de diferentes computadores e os apresenta como um sistema uniforme a usuários e aplicações. A última camada é constituída pelo CM (Cloud Manager), que age como a interface entre os usuários e a infraestrutura, implementa a lógica de negócio do provedor e aborda questões de segurança e QoS (Quality of Service) (CELESTI et al., 2013). Esta camada é, portanto, responsável pelo Acordo de Nível de Serviço (SLA – Service Level Agreement), que é o acordo legal firmado entre o provedor de serviços e o cliente a fim de garantir a qualidade de serviço requerida. O SLA define uma lista de serviços e seus respectivos atributos de qualidade, como tempo de resposta, disponibilidade, confiabilidade e custo (MENASCE; ALMEIDA; DOWDY, 2004). 19 Figura 1 – Camadas da implementação de uma nuvem. Fonte: Acervo do autor. 2.1.5 Computação em Nuvem Verde A Computação em Nuvem Verde, do inglês Green Cloud Computing, visa o uso eficiente da infraestrutura de computação em nuvem. Assim, difere da abordagem de nuvem convencional, uma vez que leva em consideração a eficiência energética em datacenters, cujos recursos devem ser alocados de forma que não apenas se cumpram os requisitos de QoS definidos no SLA, mas também que seja possível reduzir o uso de energia elétrica (BUYYA; BELOGLAZOV; ABAWAJY, 2010). De acordo com Beloglazov et al. (2011, p. 11), “a principal causa de ineficiência energética em datacenters é a baixa média de utilização dos recursos”5 ocasionada devido à variabilidade da carga de trabalho, que obriga os datacenters a serem equipados para suprir picos de carga que raramente acontecem na prática. Como consequência, os recursos computacionais encontram-se subutilizados a maior parte do tempo e, nesta condição, a eficiência energética das máquinas físicas é mínima. Estas afirmações estão baseadas na constatação de que o consumo de energia do hardware não é proporcional à carga de trabalho. Como descrito por Bose et al. (2011), ambientes de nuvem convencional utilizam técnicas de balanceamento de carga, que distribuem igualmente as solicitações recebidas entre um grupo de MFs. Dessa forma, os servidores operam com o mínimo possível de carga para garantir alta performance e, consequentemente, atender às exigências de qualidade de serviço. O modelo de nuvem verde, por outro lado, baseia-se na consolidação de carga, que consiste 5 Texto original traduzido por esta autora: “The main reason of the power inefficiency in data centers is low average utilization of the resources”. 20 em agrupar a carga de trabalho no menor número possível de recursos físicos e desligar ou colocar em modo de baixo consumo energético os recursos ociosos a fim de reduzir o consumo de energia elétrica sem violar o SLA (BUYYA; BELOGLAZOV; ABAWAJY, 2010). Portanto, segundo Werner et al. (2012, p. 1), o desafio em nuvem verde “é a operação com o montante mínimo de recursos ativos, sem deixar de atender às exigências de qualidade de serviço e de robustez”. Em relação à arquitetura de uma nuvem verde, Buyya, Beloglazov e Abawajy (2010) propõem um modelo composto por quatro entidades: os Consumidores ou os Brokers que os representam, que solicitam o serviço da Nuvem; o Alocador de Serviço Verde, que funciona como uma interface entre a infraestrutura da nuvem e os consumidores; as Máquinas Virtuais, que podem ser dinamicamente ativadas ou desativadas em uma máquina física ou migradas entre diferentes MFs a fim de consolidar a carga de trabalho; e as Máquinas Físicas. Para que o Alocador de Serviço Verde possa gerenciar os recursos de forma eficiente energeticamente, é necessária a interação entre alguns componentes, como o Monitor de Energia, que observa e determina quais máquinas físicas devem ser ligadas ou desligadas; e o Escalonador de Serviço, que atribui solicitações a MVs, determina direitos de recursos alocados para MVs e decide quando adicionar ou remover MVs para atender à demanda. Este modelo é demonstrado na Figura 2. Figura 2 – Arquitetura de nuvem verde e seus componentes. Fonte: Adaptado de BUYYA; BELOGLAZOV; ABAWAJY, 2010. Como o desafio da Computação em Nuvem Verde é consolidar a carga de trabalho sem violar o SLA, diferentes algoritmos e políticas de consolidação são propostos 21 por pesquisadores. Para validá-los, contudo, é essencial que sejam avaliados em infraestruturas virtualizadas de grande escala. Logo, por ser extremamente complicado conduzir experimentos em infraestruturas reais, simulações têm sido utilizadas como forma de avaliar o desempenho de tais propostas, visto que possibilitam a realização de testes em ambientes de larga escala e garantem que experimentos possam ser reproduzidos e repetidos (BELOGLAZOV, 2013). 2.2 SIMULAÇÃO A simulação, como definido por Shannon (1998, p. 1), é “o processo de projetar um modelo de um sistema real e conduzir experimentos com este modelo a fim de entender o comportamento do sistema e/ou avaliar diversas estratégias para o seu funcionamento” 6. A simulação pode ser vista como uma metodologia experimental e aplicada que imita o funcionamento de um processo ou sistema real ao longo do tempo (BANKS, 1999). Simulações são utilizadas para, além de descrever e analisar o funcionamento de um sistema, prever comportamentos futuros deste e responder questões do tipo “O que aconteceria se?”, a fim de resolver problemas reais (Banks, 1999). De acordo com Carson (2004), a avaliação, a comparação e a análise são os principais motivos para a realização de simulações, enquanto que a predição do desempenho e a identificação de problemas do sistema, bem como suas causas, constituem os principais resultados. 2.2.1 Conceitos relacionados Há diversos termos e conceitos fundamentais envolvidos na modelagem e na simulação de sistemas (BANKS, 1999). Os mais relevantes para este trabalho são descritos a seguir: sistema: consiste em um grupo ou coleção de elementos inter-relacionados que cooperam entre si para atingir um determinado objetivo (SHANNON, 1998). Freitas Filho (2008, p. 25) define um sistema como “um grupo de componentes que recebem estímulos ou entradas (inputs) e produzem respostas ou saídas (outputs)”; 6 Texto original traduzido por esta autora: “the process of designing a model of a real system and conducting experiments with this model for the purpose of understanding the behavior of the system and/or evaluating various strategies for the operation of the system”. 22 modelo: é uma representação descritiva de um processo ou sistema real, que geralmente apresenta parâmetros que o tornam configurável (CARSON, 2004). O modelo deve ser projetado de forma que o seu comportamento imite o comportamento de resposta do sistema real a eventos que ocorrem ao longo do tempo (SHANNON, 1998) e deve ser simples, porém o suficientemente complexo para responder as questões levantadas (BANKS, 1999). Segundo Carson (2004), o excesso de detalhes em um modelo pode conduzir o projeto ao fracasso; estado do sistema: é uma lista de valores capazes de definir o sistema em qualquer instante. Na prática, é definido implicitamente pelos status internos de todas as entidades pertencentes à simulação (CARSON, 2004); eventos: são acontecimentos que, de acordo com Carson (2004), mudam o estado do sistema e podem ser classificados como primários (programados para ocorrer em um momento futuro através de dados e suposições estatísticas) e secundários (programados para ocorrer imediatamente segundo a lógica interna do modelo); entidade: representa um objeto real no modelo e pode ser dinâmica, quando se move através do sistema; ou estática, quando serve a outras entidades (BANKS, 1999). Tarefas que chegam e deixam a CPU (Central Processing Unit) depois de processadas são exemplos de entidades dinâmicas e a própria CPU, de entidade estática (FREITAS FILHO, 2008); atributos: constituem características associadas a uma entidade específica, como nome, prioridade ou tempo de processamento necessário (SHANNON, 1998). Os atributos devem, portanto, ser considerados como valores locais (BANKS, 1999); variável de estado: é toda informação necessária para determinar o que está acontecendo no sistema em um determinado momento (BANKS, 1999). Para que a execução de uma simulação interrompida possa ser retomada do ponto em que foi parada, todas as variáveis de estado devem ter seus valores conhecidos no momento da interrupção, uma vez que estes representam o estado do sistema (FREITAS FILHO, 2008); recurso: constitui uma entidade estática que fornece serviços a uma ou mais entidades dinâmicas simultaneamente e pode apresentar diversos 23 estados. Os mais comuns são ocupado e ocioso, mas há outras possibilidades, como falhado, bloqueado ou indisponível (BANKS, 1999); tempo de atividade: período que corresponde a uma ação cuja duração é predeterminada, ou seja, é conhecida antes do início da atividade. Esta duração pode ser uma constante ou resultado de uma expressão matemática (FREITAS FILHO, 2008); tempo de espera ou delay: período que corresponde a uma ação cuja duração é indefinida, pois depende de outros eventos. Logo, constitui o oposto de uma atividade (BANKS, 1999); processo: é uma sequência de eventos, atividades e tempos de espera associados a uma entidade à medida que esta se move pelo sistema (CARSON, 2004); processamento de listas: corresponde à forma como uma fila de entidades que estão aguardando os recursos solicitados é gerenciada. As filas são representadas por listas ordenadas e a política de processamento mais utilizada é a FIFO (First In, First Out), na qual o primeiro a chegar é o primeiro a ser atendido (FREITAS FILHO, 2008); modelo de simulação de eventos discretos: modelo no qual as variáveis de estado são modificadas apenas em momentos definidos, ou seja, permanecem inalteradas durante intervalos de tempo e mudam quando um evento ocorre (BANKS, 1999); modelo de simulação contínuo: modelo no qual as variáveis de estado são modificadas continuamente ao longo do tempo (FREITAS FILHO, 2008); simuladores: são softwares que realizam simulações e, muitas vezes, contêm pacotes com modelos que necessitam apenas de dados de entrada para funcionar (BANKS, 1999). 2.2.2 Vantagens e desvantagens A simulação para a análise de sistemas apresenta diversas vantagens em comparação com os modelos analíticos ou matemáticos e com a realização de testes em ambientes reais (SHANNON, 1998). Os principais benefícios citados na literatura são descritos a seguir: 24 a simulação permite avaliar, uma vez criado o modelo de simulação, políticas e métodos de funcionamento sem as despesas e o transtorno de realizar experimentos com o sistema real (BANKS, 1999); simulações possibilitam a identificação de “gargalos” e, por conseguinte, a descoberta das causas de demoras em diversos processos (BANKS, 1999); através de simulações, é possível testar hipóteses sobre como ou por que um determinado fenômeno ocorre no sistema (SHANNON, 1998); o processo de simular permite controlar o tempo, comprimindo-o ou expandindo-o de forma a acelerar ou retardar um fenômeno para que este possa ser meticulosamente investigado (BANKS, 1999). Conforme Shannon (1998), é possível simular meses ou anos de operação de um sistema em questão de segundos, bem como desacelerar um fenômeno momentâneo para estudá-lo; estudos de simulação mostram como um sistema realmente opera, em vez de indicar previsões sobre seu funcionamento realizadas por um indivíduo (BANKS, 1999) e auxiliam na identificação das variáveis mais relevantes para o seu desempenho (SHANNON, 1998); simulações permitem estudar como um sistema se modifica ao longo do tempo e como seus subsistemas e componentes interagem (CARSON, 2004); o ato de simular possibilita entender por que um determinado fenômeno ocorre, uma vez que permite ver e controlar o sistema em sua totalidade (BANKS, 1999); a simulação permite diagnosticar problemas através de modelos complexos e, portanto, de alta fidelidade; bem como compreender seus efeitos no sistema (BANKS, 1999); normalmente, o custo de um estudo de simulação corresponde a menos de 1% do total gasto para a implementação de um sistema e é, portanto, um investimento inteligente (BANKS, 1999); um estudo de simulação permite testar todos os aspectos de um sistema sem que seja necessário adquirir e implantar os recursos físicos (BANKS, 1999); 25 um modelo de simulação fornece o único método para estudar sistemas dinâmicos complexos que ainda não foram implementados e para os quais os modelos analíticos ou estáticos apresentam baixas fidelidade e acurácia (CARSON, 2004); Embora o processo de simulação seja uma excelente ferramenta de análise, apresenta algumas desvantagens (FREITAS FILHO, 2008). Entre elas: a criação de modelos exige treinamento especializado (BANKS, 1999); como as saídas das simulações são, geralmente, variáveis aleatórias, seus resultados podem ser difíceis de interpretar (BANKS, 1999). Em muitos casos, é trabalhoso determinar se uma saída está associada a “alguma relação significante no sistema ou a processos aleatórios construídos e embutidos no modelo” (FREITAS FILHO, 2008, p. 27); a modelagem e a análise de simulações podem consumir muitos recursos, como tempo e capital (CARSON, 2004); modelos de simulação não fornecem uma solução otimizada, mas uma ferramenta de análise do comportamento de um sistema sob condições específicas (SHANNON, 1998); simulações podem ser usadas de forma inapropriada. Há situações em que uma solução analítica, por exemplo, seria adequada ou até melhor (BANKS, 1999). 2.3 CLOUDSIM O CloudSim é uma ferramenta extensível de código aberto para simulação de sistemas computacionais em nuvem desenvolvida na Universidade de Melbourne, na Austrália. Este framework foi projetado especificamente para modelagem e simulação de infraestruturas de computação em nuvem, visto que os simuladores então disponíveis eram voltados à Computação em Grade (Grid Computing) e, portanto, não ofereciam suporte ao isolamento das abstrações das camadas de serviços (SaaS, PaaS e IaaS) e à simulação de ambientes virtualizados, nem ferramentas para a modelagem de datacenters com grandes quantidades de servidores (CALHEIROS et al., 2011). O simulador CloudSim, segundo Calheiros et al. (2011), oferece como principais recursos: suporte à modelagem e simulação de ambientes computacionais em nuvem de grande escala em um único computador e com baixo consumo de recursos computacionais; 26 plataforma autônoma para modelagem de nuvens, agentes de serviços e políticas de alocação; mecanismo de virtualização, que auxilia na criação e no gerenciamento de múltiplos serviços em um nó do datacenter; flexibilidade de troca entre diferentes políticas de alocação de núcleos de processamento; e criação dinâmica de entidades. A partir da versão 2.0, através de extensões, o CloudSim permite realizar simulações que levam em consideração o consumo de energia elétrica (capacidade que não era contemplada pelo núcleo do framework). Foi incorporada também a possibilidade de simular aplicações com cargas de trabalho dinâmicas (BELOGLAZOV, 2013). 2.3.1 Funcionamento do CloudSim Para dar sustento à realização das extensões e simulações propostas, nesta seção, são explicados os métodos de modelagem de componentes, o processamento interno de aplicações e o fluxo de comunicação entre entidades do CloudSim conforme descrito por Calheiros et al. (2011). 2.3.1.1 Modelagem da nuvem No CloudSim, uma entidade é uma instância de um componente. Este, por sua vez, pode ser uma classe ou um conjunto de classes que representam um modelo. Assim, na modelagem de uma nuvem, Datacenter é uma entidade que gerencia máquinas físicas, às quais são atribuídas máquinas virtuais por meio de uma política de alocação definida pelo provedor de Nuvem. As máquinas físicas, por sua vez, são representadas pelo componente Host, que possui atributos como capacidade de processamento, memória, armazenamento e política de alocação de núcleos de processamento a máquinas virtuais. A alocação de máquinas virtuais em uma nuvem refere-se ao processo de criar instâncias destas em máquinas físicas que atendem aos requisitos de hardware, como número de núcleos de processamento e quantidade de memória. Assim, cada componente Host instancia um componente VmScheduler, que representa uma política de alocação de núcleos a MVs (por espaço ou tempo compartilhado). 27 2.3.1.2 Modelagem da alocação de máquinas virtuais A alocação de máquinas virtuais leva em consideração a capacidade de processamento e a largura de banda disponíveis na máquina física, uma vez que as MVs, apesar de executarem em contextos isolados, compartilham os núcleos de processamento e o barramento de sistema. No CloudSim, a alocação é realizada em dois níveis: na máquina física e na máquina virtual. No primeiro, é especificada a quantidade de poder de processamento de cada núcleo que será atribuído a cada MV. No segundo, cada tarefa recebe um valor fixo do poder de processamento disponível na máquina virtual. Em ambos os níveis, são implementadas duas políticas básicas de provisionamento: tempo compartilhado e espaço compartilhado. Na Figura 3, são mostrados os quatro cenários possíveis para o uso de tais políticas. O simulador permite também que políticas personalizadas sejam criadas por desenvolvedores por meio de extensões às classes existentes. Figura 3 – Políticas de alocação: (a) Espaço compartilhado para MVs e tarefas, (b) Espaço compartilhado para MVs e tempo compartilhado para tarefas, (c) Tempo compartilhado para MVs e espaço compartilhado para tarefas, (d) Tempo compartilhado para MVs e tarefas. Fonte: Adaptado de CALHEIROS et al., 2011. 2.3.1.3 Modelagem do comportamento da rede A inclusão da topologia de rede e seu comportamento no modelo é uma consideração importante, uma vez que a latência das mensagens trocadas entre entidades da nuvem afeta o desempenho geral das aplicações e pode ocasionar violações ao SLA. 28 No CloudSim, a latência do tráfego da rede é simulada através de informação armazenada em uma matriz de latência m x n, em que cada posição eij representa o tempo de transferência de uma mensagem da entidade i para a entidade j. Assim, um evento é transmitido entre i e j pelo mecanismo de gerenciamento de eventos quando o tempo total da simulação é igual ao tempo em que a mensagem foi enviada mais a latência de rede entre as duas entidades. A topologia da rede é armazenada em um arquivo BRITE (Boston university Representative Internet Topology gEnerator). Este arquivo contém os nós da rede, que representam entidades do CloudSim, como máquinas físicas e datacenters, e é lido pelo simulador e utilizado para gerar a matriz de latência. Mensagens enviadas entre entidades do CloudSim constituem eventos e são processadas por um objeto NetworkTopology, que possui a informação sobre a topologia da rede. Este objeto acrescenta o valor de latência ao evento e o transfere para o motor de gerenciamento de eventos para processamento adicional. 2.3.1.4 Modelagem de cargas de trabalho dinâmicas O CloudSim suporta a simulação de aplicações que apresentam comportamentos dinâmicos em relação à carga de trabalho, à disponibilidade e à escalabilidade. Para tanto, é necessário implementar um modelo de utilização, que define a demanda de processamento de uma aplicação, ou utilizar um dos modelos já disponíveis no simulador. O simulador permite também a modelagem e a simulação de violações ao SLA, através de políticas que definem quando estas violações podem ocorrer; e da contagem do número de violações e de recursos que foram requisitados, mas não alocados. 2.3.1.5 Modelagem do consumo de energia do datacenter Ambientes de computação em nuvem, com sua infraestrutura e sistemas de refrigeração, podem consumir grande quantidade de energia elétrica. No CloudSim, é possível gerenciar tal consumo através do objeto PowerModel, que pode ser estendido para suportar a definição e a simulação de diferentes modelos de consumo e técnicas de gerenciamento de energia. O simulador permite ainda a criação de políticas de provisionamento e o cálculo da energia total consumida por um sistema durante o período de simulação. 29 2.3.1.7 Processamento interno do datacenter O processamento das aplicações é feito pelas máquinas virtuais, que monitoram e atualizam seu progresso continuamente. Um evento interno é gerado para informar à entidade Datacenter que uma aplicação será finalizada em breve. Assim, a cada passo da simulação, esta entidade chama um método que faz com que todas as máquinas físicas atualizem os status de suas máquinas virtuais e aciona outro método. Este, por sua vez, faz com que as máquinas virtuais atualizem os status de suas aplicações ativas e retornem o tempo do próximo evento. As máquinas físicas, então, enviam os menores tempos de finalização para o Datacenter. Estes tempos são armazenados em uma fila, que é consultada pela entidade Datacenter após cada processamento de evento. A Figura 4 exibe esta sequência de atualização do processamento de aplicações. Figura 4 – Diagrama de sequência do processamento de aplicações. Fonte: Adaptado de CALHEIROS et al., 2011. 2.3.1.8 Comunicação entre entidades O CloudSim é um simulador baseado em eventos e, portanto, as diferentes entidades de um sistema simulado comunicam-se por meio do envio de eventos. O fluxo 30 básico desta comunicação, demonstrado na Figura 5, inicia-se com o registro da entidade Datacenter no CIS (Cloud Information Service). Em seguida, quando uma aplicação é enviada pelo usuário, o DatacenterBroker consulta o CIS para identificar os provedores de nuvem cujas infraestruturas atendam aos requisitos de software, hardware e QoS desta. Quando identificados, o DatacenterBroker negocia e realiza a implantação de máquinas virtuais, que executarão a aplicação, em uma ou mais máquinas físicas de um Datacenter sugerido pelo CIS. Depois de finalizada a execução das tarefas, as MVs são destruídas. Figura 5 – Diagrama de sequência da comunicação entre entidades. Fonte: Adaptado de CALHEIROS et al., 2011. 2.3.2 Arquitetura do CloudSim O framework CloudSim possui uma arquitetura constituída por três camadas: camada do núcleo do simulador: é a camada inferior, onde a simulação é processada. Nesta camada, é realizado o controle da execução e das filas de eventos; camada de simulação do CloudSim: é a camada intermediária, que contém as classes de entidades que compõem o ambiente de computação em nuvem, como máquinas físicas, máquinas virtuais, datacenter e PE (Processing Element), e estão distribuídas entre as subcamadas Estruturas de Interface do Usuário, Serviços da Máquina Virtual, Serviços da Nuvem, Recursos da Nuvem e Rede. Esta camada é ainda responsável pela 31 alocação de MVs a máquinas físicas, pelo gerenciamento da execução de aplicativos e pelo monitoramento do estado do sistema dinâmico; camada de usuário: é a camada superior da arquitetura, na qual é definido o cenário da simulação através da configuração de entidades básicas, como máquinas físicas (quantidade e suas especificações); aplicações (números de tarefas e suas requisições); máquinas virtuais; número de usuários; tipos de aplicações; e políticas de escalonamento. A Figura 6 ilustra as três camadas do CloudSim e seus componentes. Figura 6 – Arquitetura de camadas do CloudSim. Fonte: CALHEIROS et al., 2011. 2.3.3 Estrutura do CloudSim As principais classes que compõem o simulador, de acordo com Calheiros et al. (2011), são descritas a seguir: BwProvisioner: classe abstrata que representa a política de provisionamento de largura de banda a máquinas virtuais. Por padrão, é estendida pela classe BwProvisionerSimple (que permite a uma máquina virtual reservar a largura de banda necessária desde que esta quantidade esteja disponível na máquina física), mas pode ser estendida por outras 32 classes criadas por pesquisadores e desenvolvedores para modelar novas políticas que atendam às necessidades de determinadas aplicações; Cloudlet: classe que modela as aplicações que executam na nuvem. Cada aplicação possui um tamanho de instrução predeterminado e overhead de transferência de dados e armazena informações como o id da máquina virtual na qual é executada, o tamanho, o número de núcleos de processamento requeridos para sua execução e seu status; CloudletScheduler: classe abstrata que pode ser estendida de forma a implementar diferentes políticas de compartilhamento do poder de processamento de uma máquina virtual entre as aplicações que nela são executadas. Duas classes que a estendem são oferecidas pelo CloudSim: CloudletSchedulerSpaceShared (espaço compartilhado) e Cloudlet- SchedulerTimeShared (tempo compartilhado); Datacenter: classe que modela a infraestrura oferecida como serviço pelos provedores de computação em nuvem e consiste em um conjunto de máquinas físicas com configurações de hardware (como memória, quantidade de núcleos e capacidade de armazenamento) que podem ser homogêneas ou heterogêneas; DatacenterBroker: classe que modela um agente que opera em nome do usuário e é responsável pela mediação das negociações entre ele e o provedor de nuvem. Primeiro, o agente busca provedores de serviços apropriados no CIS e, em seguida, realiza negociações de alocação de recursos e serviços para atender aos requisitos de QoS. É possível estender esta classe para a implementação de políticas de mediação personalizadas; DatacenterCharacteristics: classe que contém as propriedades dos recursos do datacenter, como arquitetura, sistema operacional, política de alocação, VMM e custos; Host: classe que modela um recurso físico (servidores de computação ou armazenamento) e seus atributos, como quantidade de memória e capacidade de armazenamento; política para o compartilhamento do poder de processamento entre MVs; e políticas de provisionamento de memória e largura de banda para MVs; 33 NetworkTopology: classe que armazena informações sobre o comportamento da rede em uma simulação, através de matrizes de latência e de largura de banda e sobre sua topologia, gerada a partir de um arquivo BRITE; RamProvisioner: classe abstrata que representa a política de provisionamento de memória RAM (Random Access Memory) a máquinas virtuais e é responsável por verificar se o recurso físico possui memória (livre) suficiente para a implantação e execução de determinada MV. É estendida pela classe RamProvisionerSimple, que aloca a quantidade de memória requisitada pela máquina virtual, exceto se esta for maior que a memória disponível. Neste caso, o pedido é simplesmente rejeitado; HarddriveStorage: classe que representa uma rede de armazenamento composta por um conjunto de discos rígidos conectados através de uma LAN (Local Access Network). Implementa uma interface que pode ser utilizada para simular armazenamento e recuperação de qualquer quantidade de dados, desde que a rede disponha da largura de banda necessária; Vm: classe que modela uma máquina virtual, gerenciada e hospedada por uma máquina física. Possui características como número de processadores, quantidade de memória RAM e política de alocação interna; VmAllocationPolicy: classe abstrata que representa a política de alocação de máquinas virtuais a máquinas físicas e tem como principal função selecionar um recurso físico que atenda às exigências de memória, armazenamento e disponibilidade para a implantação de uma MV. Este processo é realizado em dois estágios: primeiro, a máquina física é reservada e, depois da confirmação do usuário, a máquina virtual é efetivamente alocada. A política padrão utilizada é implementada pela classe VmAllocationPolicySimple e escolhe a máquina física com menor número de PEs em uso para alocar uma máquina virtual; VmScheduler: classe abstrata que representa a política de compartilhamento do poder de processamento entre as máquinas virtuais que executam em uma mesma máquina física. Pode ser estendida para suportar políticas específicas. 34 A Figura 7 apresenta as classes do CloudSim descritas anteriormente e as relações entre elas. Figura 7 – Diagrama de classes UML do CloudSim. Fonte: Adaptado de CALHEIROS et al., 2011. No núcleo da arquitetura, encontra-se o motor de simulação do CloudSim, responsável pela criação e gerenciamento de eventos. As classes que compõem tal motor são descritas a seguir: CloudSim: classe principal, que é responsável por gerenciar filas de eventos e controlar a execução destes passo a passo. Cada evento gerado por esta entidade em tempo de execução é armazenado em uma fila de eventos futuros, ordenada pelo atributo tempo. Quando o tempo de simulação coincide com o tempo em que um evento está agendado para ocorrer, este é transferido para a fila de eventos diferidos e um método de processamento de eventos é chamado para realizar as ações necessárias; DeferredQueue: classe que implementa a fila de eventos diferidos usada pela entidade CloudSim; FutureQueue: classe que implementa a fila de eventos futuros usada pela entidade CloudSim; CloudInformationService: classe que permite o registro de entidades e a descoberta de recursos disponíveis de outras entidades; 35 SimEntity: classe abstrata que representa uma entidade da simulação capaz de enviar mensagens a outras entidades; processar mensagens recebidas; e disparar e manipular eventos; CloudSimTags: classe que contém etiquetas de comando que indicam o tipo de ação que deve realizada por entidades ao receberem ou enviarem eventos; SimEvent: classe que representa um evento enviado entre entidades e possui atributos como tipo, tempo de inicialização, tempo em que o evento deve ocorrer e tempo de finalização; CloudSimShutdown: classe responsável por indicar o término de uma simulação ao CIS; Predicate: classe usada para determinar a seleção de eventos da fila de eventos deferidos. É estendida pelas classes: PredicateAny (qualquer evento da fila é selecionado); PredicateFrom (seleciona eventos disparados por uma entidade específica); PredicateNone (não corresponde a nenhum evento da fila); PredicateNotFrom (seleciona eventos que não foram enviados por uma dada entidade); PredicateNotType (eventos que não correspondem a determinados marcadores são selecionados); e PredicateType (seleciona eventos com marcadores específicos). A Figura 8 demonstra o diagrama de classes UML do núcleo de simulação do CloudSim, formado por suas classes principais e pelos seus predicados. Figura 8 – Diagrama de classes UML do núcleo do CloudSim. Fonte: CALHEIROS et al., 2011. 36 2.4 TRABALHOS CORRELATOS Nesta seção, são descritos os principais trabalhos relacionados a esta pesquisa. Os dois primeiros consistem em modelos de gerenciamento para a redução do consumo de energia elétrica em ambientes de nuvem verde e estão relacionados à motivação deste projeto. Os demais referem-se a simuladores desenvolvidos a partir do CloudSim: TeachCloud, CloudReports e NetworkCloudSim. 2.4.1 Modelos de Gerenciamento de Nuvem Verde Werner (2011) propõe um modelo de alocação e distribuição de máquinas virtuais como solução para o controle integrado de servidores e sistemas de suporte em nuvem verde. Esta abordagem considera um sistema de gerenciamento com múltiplos componentes e é baseada no OTM (Organization Theory Model), através do qual são definidos os padrões de interação entre tais componentes e as regras de funcionamento. Com base em normas, papéis, regras e crenças, este modelo prevê quando máquinas virtuais devem ser desligadas, redimensionadas ou migradas e quando máquinas físicas devem ser ligadas ou desligadas em função da carga de trabalho e das exigências do SLA. A abordagem define ainda quando o desligamento ou o religamento dos sistemas de suporte é necessário. A proposta foi validada por meio de simulações de diferentes cenários e, segundo Werner (2011), demonstrou ser eficiente, com uma economia de até 40% de energia elétrica em comparação com o modelo de nuvem convencional. Villarreal e Westphall (2013) realizaram extensões à proposta de Werner (2011) a fim de acrescentar-lhe o gerenciamento dos equipamentos de rede legados, cujo consumo é praticamente independente da carga de trabalho. O novo modelo visa tornar o consumo destes equipamentos aproximadamente proporcional à carga e fazer com que a energia elétrica por eles economizada contribua para a eficiência total do sistema. Para a consolidação do tráfego da rede, foram elaboradas regras e crenças que regem a correta configuração desta em função da consolidação de carga nos servidores. Os autores desenvolveram ainda um modelo para gerar a topologia da rede do datacenter em função do número de servidores físicos e definiram regras e fórmulas para calcular o consumo dos switches e da rede completa. 37 O modelo proposto é baseado na topologia de rede padrão de um datacenter, mostrada na Figura 9, que é composta por três camadas de switches: acesso, agregação e núcleo. Nesta configuração, existe redundância nas conexões entre camadas e cada rack acomoda até 40 máquinas físicas e dois switches de camada de acesso, sendo que cada MF possui uma placa de rede conectada a cada switch de acesso do rack ao qual pertence. Os autores consideram que cada switch de acesso possui 48 portas downlink, isto é, portas para conexão com a camada imediatamente inferior, com velocidade Giga Ethernet e 2 portas uplink (para conexão com a camada superior) com velocidade 10 Giga Ethernet. Os switches da camada de agregação, por sua vez, possuem 24 portas downlink 10 Giga Ethernet e 2 portas uplink 40 Giga Ethernet. Já os switches de núcleo são compostos por módulos de 24 portas com velocidade 40 Giga Ethernet. Assim, o modelo estabelece que até 12 racks podem ser atendidos por 2 switches de camada de agregação; que, com menos de 12 racks, não são necessários switches de camada de núcleo; e que até 144 racks podem ser atendidos por dois switches de camada de núcleo com um módulo cada. Desta forma, é possível determinar a quantidade de cada tipo de switch e suas interconexões a partir da quantidade de máquinas físicas. Figura 9 – Topologia de rede padrão de um datacenter. Fonte: Adaptada de VILLARREAL; WESTPHALL, 2013. A economia energética proposta pelo sistema baseia-se no desligamento de portas, módulos e switches inativos e na redução da velocidade de portas. O cálculo do consumo dos switches é realizado através da soma do consumo base de cada tipo de switch com o 38 somatório dos consumos das portas. Este último depende da quantidade de portas ativas e da velocidade configurada para cada porta. Esta abordagem foi validada com um modelo analítico simples. No entanto, os autores descrevem um modelo de simulação e sugerem como trabalhos futuros realizar extensões ao simulador CloudSim para implementar tal modelo e executar experimentos a fim de determinar tanto as regras mais eficientes quanto a contribuição e o impacto do modelo em cenários com diferentes cargas de trabalho. 2.4.2 TeachCloud O TeachCloud é uma ferramenta para modelagem e simulação de ambientes de computação em nuvem voltada para o ensino e construída sobre a plataforma do CloudSim. Entre os aprimoramentos e extensões introduzidas ao CloudSim pelo TeachCloud, pode-se citar: interface gráfica para auxiliar os alunos a criarem os componentes de uma nuvem; gerador de carga de trabalho Rain; módulos para a especificação de SLA; modelos de redes para representar topologias existentes em ambientes de nuvem reais; monitoramento da maior parte dos componentes de um sistema; e um módulo que permite aos estudantes reconfigurar a nuvem e estudar o impacto das mudanças no desempenho do sistema (JARARWEH et al., 2012). O código do TeachCloud, segundo os autores, seria disponibilizado para pesquisadores e estudantes. No entanto, o desenvolvimento foi descontinuado e todo o conteúdo foi retirado do website do simulador7. 2.4.3 CloudReports O CloudReports, desenvolvido na Universidade Federal do Ceará, é uma ferramenta que utiliza o CloudSim como motor de simulação e provê atributos como: interface gráfica, geração de relatórios e criação de extensões através de plugins que podem ser conectados em tempo de execução sem a necessidade de recompilar o código fonte. No entanto, o conjunto de extensões suportadas limita-se a apenas determinados tipos de algoritmos, como: políticas de alocação de VMs e de provisionamento de recursos; 7 Endereço do website do TeachCloud: https://code.google.com/p/teachcloud/. 39 escalonadores de MVS e aplicações; e modelos de consumo de energia e modelos de utilização (SÁ, 2013). 2.4.4 NetworkCloudSim O NetworkCloudSim é um framework de simulação de ambientes de computação em nuvem, cujos componentes foram implementados como parte do simulador CloudSim a fim de dotá-lo de recursos para a modelagem do comportamento de aplicações e da rede interna do datacenter. Foi desenvolvido por Garg e Buyya (2011) com o intuito de fornecer um modelo escalável e generalizado de aplicação e de rede. Para a modelagem de diferentes topologias de rede, o NetworkCloudSim apresenta as classes: Switch, que representa uma entidade que pode ser configurada como um roteador ou um switch e modela atrasos no encaminhamento de dados a outras entidades; e NetworkPacket e HostPacket, que modelam, respectivamente, pacotes que viajam pela rede virtual e pacotes que são transmitidos de um servidor a outro e, portanto, representam um fluxo de dados entre MVs em um datacenter. Já para a modelagem de aplicações, foram desenvolvidas as classes: NetworkCloudlet, que é uma extensão da classe Cloudlet do CloudSim e representa uma tarefa generalizada com vários estágios; e AppCloudlet, que representa uma aplicação com múltiplas tarefas (GARG; BUYYA, 2011). O NetworkCloudSim, contudo, é voltado para a representação do tráfego da rede e não suporta o gerenciamento e o cálculo do consumo elétrico dos equipamentos. 40 3 DESENVOLVIMENTO Neste capítulo, é detalhado o desenvolvimento das extensões realizadas ao simulador CloudSim. São relacionados os requisitos funcionais e não funcionais que devem ser atendidos por tais extensões e é apresentada a especificação do projeto, através dos diagramas de casos de uso, de classes, de sequência e de atividades. São descritos ainda a implementação e o funcionamento das classes e dos algoritmos desenvolvidos, bem como os testes realizados. Por fim, são demonstradas e discutidas as simulações executadas e os resultados obtidos. 3.1 DESCRIÇÃO As extensões desenvolvidas adicionam ao CloudSim a capacidade de definir uma topologia de rede e representar e gerenciar seus componentes para realizar simulações que consideram o consumo energético da rede do datacenter a fim de validar o sistema proposto por Villarreal e Westphall (2013). Este sistema, conforme descrito no capítulo 2, propõe extensões a um modelo de gerenciamento de nuvem verde para gerenciar equipamentos de rede legados de forma a tornar seu comportamento aproximadamente proporcional à carga de trabalho e baseia-se na desconexão de portas, módulos e switches inativos e na redução da velocidade de portas. Os autores propõem também um modelo de simulação baseado na topologia padrão de um datacenter que, a partir da quantidade de máquinas físicas, determina os equipamentos de rede necessários e suas interconexões e em uma fórmula para o cálculo do consumo dos switches em função da quantidade de portas ativas e das velocidades das mesmas. Desta forma, as extensões implementadas permitem simular e modelar a rede de acordo com a topologia padrão definida, gerenciá-la conforme as regras estabelecidas no modelo em função das mudanças de estados das máquinas físicas do datacenter e calcular a energia consumida durante sua operação. 3.2 REQUISITOS Os requisitos que devem ser atendidos pelas extensões ao CloudSim foram levantados e revisados junto aos pesquisadores responsáveis pelo modelo de gerenciamento mediante entrevistas e são especificados nos Quadros 1 e 2: 41 Quadro 1 – Requisitos funcionais. REQUISITOS FUNCIONAIS RF01: Permitir definir o cenário da simulação, incluindo características das máquinas físicas, das máquinas virtuais, das aplicações e dos equipamentos de rede do datacenter. RF02: Definir a topologia da rede a partir do número de máquinas físicas. RF03: Representar os switches de acesso, agregação e núcleo e suas mudanças de estado. RF04: Interagir com o CloudSim para que os eventos da simulação provoquem as mudanças correspondentes no estado da rede. RF05: Ligar e desligar equipamentos de rede e portas em função da consolidação de carga das máquinas físicas. RF06: Configurar a velocidade das portas dos equipamentos de rede em função da utilização das máquinas físicas e da largura de banda agregada. RF07: Calcular o consumo de energia elétrica dos equipamentos de rede. RF08: Em cada passo da simulação, acrescentar o consumo da rede ao consumo total do datacenter. RF09: Permitir a realização de simulações sem gerenciamento da rede. RF10: Informar as características da topologia e o consumo da rede em sua condição inicial. RF11: Gerar e salvar registros (logs) das mudanças de estado da rede. RF12: Salvar os resultados da simulação. Quadro 2 – Requisitos não funcionais. REQUISITOS NÃO FUNCIONAIS RNF01: Executar em microcomputador convencional. RNF02: Permitir simulações de 6 horas de operação de um datacenter com até 5.760 máquinas físicas com tempo de resposta menor que 1 hora. RNF03: Permitir extensão para atender outras necessidades de pesquisas. RNF04: Permitir fácil manutenção do código. RNF05: Interface gráfica para definição do cenário da simulação e exibição dos resultados. 3.3 ESPECIFICAÇÃO Para a especificação das extensões desenvolvidas, foram elaborados diagramas de acordo com a linguagem de modelagem UML e com auxílio da ferramenta Astah Community. Nesta seção, são apresentados os diagramas de casos de uso, de classes, de sequência e de atividades. 42 3.3.1 Casos de Uso Os casos de uso apresentados nesta seção, e detalhados no Apêndice A, estão relacionados aos requisitos funcionais relatados na seção anterior e demonstram as interações entre o sistema e os agentes externos. O primeiro diagrama, exibido na Figura 10, tem como ator o usuário que deseja realizar simulações e compreende os casos de uso relacionados à interação deste com o simulador através de uma interface gráfica. No segundo diagrama, apresentado na Figura 11, o ator é o próprio simulador CloudSim, que interage com as extensões desenvolvidas para reconfigurar a rede a cada mudança de estado e calcular seu consumo. Figura 10 – Diagrama de casos de uso da interação do usuário com o simulador. 43 Figura 11 – Diagrama de casos de uso da interação da interação do CloudSim com as extensões. 44 3.3.2 Diagrama de Classes O diagrama de classes, mostrado na Figura 12, representa as classes implementadas e as relações entre elas. Figura 12 – Diagrama de classes do NetPowerCloudSim. 45 3.3.3 Diagrama de Sequência O diagrama a seguir (Figura 13) mostra a sequência de criação dos objetos e as chamadas de métodos necessários para executar uma simulação com o NetPowerCloudSim. Figura 13 – Diagrama de sequência da aplicação principal. 3.3.4 Diagrama de Atividades O diagrama UML apresentado na Figura 14 demonstra o fluxo de atividades do processo de reconfiguração da rede, realizado pelo gerenciador de rede de acordo com a mudança de estado de cada máquina física do datacenter em cada frame da simulação. 46 Figura 14 – Diagrama de atividades do processo de reconfiguração da rede. 47 3.4 IMPLEMENTAÇÃO Nesta seção, são apresentadas as técnicas e as ferramentas utilizadas e é detalhada a implementação das extensões realizadas ao simulador. 3.4.1 Técnicas e ferramentas Para o desenvolvimento das extensões, foi utilizada a linguagem de programação orientada a objetos Java e o ambiente de desenvolvimento Netbeans IDE 7.3.1, em conjunto com o framework CloudSim 3.0.3 e a biblioteca gráfica Swing. A fim de auxiliar na compreensão do código e do funcionamento dos algoritmos, bem como facilitar futuras extensões, todas as classes criadas foram detalhadamente comentadas, e foi gerada documentação com a ferramenta Javadoc, fornecida pela Sun Microsystems. Os testes de unidade realizados sobre as classes desenvolvidas foram criados com auxílio do framework JUnit. 3.4.2 Codificação das extensões Para a codificação, foram consideradas duas extensões do CloudSim: o NetworkCloudSim e o PowerCloudSim. O primeiro permite representar equipamentos de rede, porém, como descrito no capítulo 2, é focado no tráfego da rede e não possui recursos para modelar o consumo de energia, o que obrigaria alterar todas as classes existentes, além de criar novas. Já o segundo, apesar de não possuir recursos para representar equipamentos de rede, permite o cálculo do consumo energético do datacenter e a migração de máquinas virtuais. Foi decidido, então, utilizar como base o PowerCloudSim, de Beloglazov e Buyya (2012), e estender suas funcionalidades para representar, gerenciar e calcular o consumo da rede. O simulador estendido foi chamado NetPowerCloudSim e acrescenta as classes PowerSwitch, herdada pelas classes PowerSwitchAcesso, PowerSwitchAgregacao e PowerSwitchNucleo; NetPowerDatacenter; GerenciadorRede; e TopologiaRede, descritas nas subseções a seguir. 48 3.4.2.1 PowerSwitch Esta classe representa um equipamento de rede do tipo switch e é estendida pelas classes PowerSwitchAcesso, PowerSwitchAgregacao e PowerSwitchNucleo, que representam switches das camadas de acesso, de agregação e de núcleo, respectivamente. Cada switch armazena seu estado, que pode ser ligado ou desligado; o estado de cada porta, que indica se está desativada ou sua velocidade (Fast Ethernet, Giga Ethernet, 10 Giga Ethernet, 40 Giga Ethernet ou 100 Giga Ethernet); seu consumo atual; seu consumo quando o frame iniciou; a largura de banda agregada; a quantidade de portas; a quantidade de portas de uplink; e a quantidade de portas ativas. Os switches possuem métodos que permitem ligá-los e desligá-los, bem como ligar e desligar portas específicas e reduzir ou aumentar sua velocidade. É possível ainda calcular seu consumo atual, a energia consumida durante um frame da simulação e a largura de banda agregada. Esta última constitui a soma das larguras de banda de todas as portas de downlink ativas. A energia consumida por um switch durante um frame da simulação é calculada por interpolação linear dos valores de consumo do switch no início do frame e o consumo atual. O Erro! Autoreferência de indicador não válida. exibe o código do método que realiza este cálculo. Quadro 3 – Código do método que calcula a energia consumida por um switch durante um frame da simulação. As classes PowerSwitchAcesso e PowerSwitchAgregacao possuem métodos para verificar se a largura de banda agregada ultrapassou ou baixou do limite estabelecido, que são usados pelo gerenciador da rede para decidir se a velocidade das portas de uplink dos switches da camada imediatamente superior deve ser, respectivamente, aumentada ou reduzida. A classe PowerSwitchNucleo possui métodos que permitem ao gerenciador da rede ligar um módulo quando está desligado e uma porta é ligada e desligar um módulo quando não possui mais portas ativas. 49 Para manter a eficiência do código, o consumo atual e a largura de banda agregada são calculados apenas quando o objeto é criado e são atualizados a cada modificação realizada em uma porta. Se os valores não fossem mantidos atualizados, ao final de cada frame da simulação, seria necessário percorrer as portas de todos os switches para calcular seus consumos e suas larguras de banda agregada. O Quadro 4 mostra o trecho do código para atualizar o consumo de um switch quando a velocidade de uma porta é aumentada. Quadro 4 – Trecho de código para atualizar o consumo atual do switch. 3.4.2.2 NetPowerDatacenter Classe que representa um datacenter com uma rede composta por máquinas físicas, switches de acesso, switches de agregação e switches de núcleo e permite calcular o seu consumo durante uma simulação. Possui como atributos o consumo total da rede, o consumo inicial da rede, o gerenciador da rede, as listas de switches e a informação sobre o gerenciamento da rede, que pode estar habilitado ou desabilitado. Esta classe estende a classe PowerDatacenter, que, por sua vez, estende a classe Datacenter para acrescentar-lhe a capacidade de calcular o consumo energético do datacenter e de realizar migração de máquinas virtuais. Assim como as classes que estende, a NetPowerDatacenter é uma entidade e, portanto, pode comunicar-se com outras entidades do CloudSim por meio da criação de eventos e do envio de mensagens e é responsável pelo avanço da simulação. Esta classe sobrescreve os métodos updateCloudletProcessing e processVmMigrate do PowerDatacenter, que são responsáveis por processar eventos da simulação, isto é, realizar as ações necessárias quando finaliza a execução de uma aplicação ou a migração de uma máquina virtual, respectivamente. Os métodos sobrescritos são invocados pelo núcleo do simulador ao final de cada frame da simulação, de acordo com o tipo de evento que o provocou. Após chamar o método correspondente da classe pai para atualizar o estado das máquinas físicas e virtuais e do datacenter, invocam os métodos verificaMudancaEstadoHost e calculaConsumoRedeFrame para atualizar o estado da rede. 50 O método verificaMudancaEstadoHost (Quadro 5) verifica a mudança de estado de cada máquina física do datacenter e a informa ao gerenciador da rede para que este a reconfigure. Quadro 5 – Trecho de código do método verificaMudancaEstadoHost. O método calculaConsumoRedeFrame, por sua vez, calcula a quantidade de energia elétrica consumida por cada switch durante o frame e acumula os valores em uma variável que representa o consumo da rede no frame. Se o gerenciamento da rede não estiver habilitado, a energia consumida em cada frame é calculada diretamente através da multiplicação do consumo inicial da rede pela duração do frame. 3.4.2.3 TopologiaRede Classe responsável por definir e representar a topologia da rede através das quantidades de racks, de switches de acesso, de switches de agregação, de switches de núcleo e de módulos por switch de núcleo e das interconexões entre seus componentes. Antes de iniciar a simulação, a partir da quantidade de máquinas físicas presentes no datacenter, o método defineTopologia calcula a quantidade de racks necessários para 51 acomodá-las. As quantidades de switches de acesso, de agregação e de núcleo são, então, calculadas a partir da quantidade de racks. O Quadro 6 apresenta o trecho de código no qual são realizados estes cálculos. Quadro 6 – Trecho do método que calcula as quantidades de racks, de switches de acesso, de switches de agregação, de switches de núcleo e de módulos por switch de núcleo. Devido à topologia padrão estabelecida no modelo, existe uma relação matemática entre o id de cada elemento da rede e o id do equipamento e o número das portas aos quais está conectado. Portanto, não há necessidade de armazenar as interconexões entre todos os componentes em estruturas de dados na classe. Quando a informação é requerida pelo simulador, a classe calcula os switches e as portas correspondentes através de fórmulas. Considera-se que os componentes da rede não podem ser conectados a uma porta diferente da que lhe corresponde de acordo com a topologia padrão. Como exemplo, é exibido no Quadro 7 o código do método que calcula os ids dos switches de acesso e o número das portas correspondentes a uma máquina física a partir de seu id. 52 Quadro 7 – Código do método que calcula os ids dos switches de acesso e o número das portas aos quais uma máquina física está conectada. 3.4.2.4 GerenciadorRede Classe que representa um gerenciador cuja função é reconfigurar a rede ao final de cada frame da simulação de acordo com as mudanças de estado das máquinas físicas. O gerenciador da rede age de acordo com as regras definidas no modelo, que determinam quando reduzir ou aumentar a velocidade de portas; ligar ou desligar portas; e ligar ou desligar módulos e switches. Antes de iniciar a simulação, o método desligaPortasSemUso, com o auxílio da classe TopologiaRede determina quais são as portas que não possuem equipamentos conectados e as desliga (Quadro 8). Este método também verifica se a largura de banda agregada dos switches que tiveram portas desligadas baixou do limite estabelecido para determinar se a velocidade de suas portas de uplink deve ser reduzida. Quadro 8 – Trecho de código do método desligaPortasSemUso que desliga as portas sem uso dos dois últimos switches de acesso. 53 O método atualizaRede, invocado pela classe NetPowerDatacenter quando há uma mudança de estado em uma máquina física, recebe o id da máquina e o tipo de mudança ocorrida e chama os métodos do objeto TopologiaRede para calcular a hierarquia de conexões entre equipamentos e o método correspondente para reconfigurar a rede. Quando uma máquina física é desligada, por exemplo, o gerenciador da rede desliga as portas dos switches de acesso às quais a máquina está conectada e verifica se ainda há portas ligadas em tais switches. Se não houver, o gerenciador desliga os switches. Se houver, verifica se a largura de banda agregada dos switches de acesso baixou do limite estabelecido. Caso esta condição seja verdadeira, a velocidade das portas é reduzida. O gerenciador, então, realiza as verificações e configurações necessárias nos switches de agregação e de núcleo, se estes existirem. A lógica completa do processo de reconfiguração da rede de acordo com as mudanças de estado das MFs está representada no diagrama de atividades apresentado na seção 3.3.4. 3.4.2.5 Classe principal e interface gráfica Para a realização de experimentos, foi desenvolvida uma classe principal, responsável por criar o cenário, iniciar a simulação e recuperar os resultados. Nela são configuradas as características de todos os objetos necessários para a simulação e os parâmetros da mesma. A fim de facilitar a execução de simulações, esta classe recebe valores ingressados através de uma interface gráfica, que possibilita definir o cenário e as características das simulações sem a necessidade de modificar ou criar código-fonte. Esta interface permite determinar a quantidade e características das máquinas físicas, das máquinas virtuais e das aplicações; indicar se a simulação deve considerar a rede e como esta deve ser gerenciada; habilitar a migração de MVs; e definir o tempo de operação do datacenter a ser simulado. É possível ainda, através desta interface, modificar os consumos base de cada tipo de switch e os consumos das portas de acordo com sua velocidade. Ao executar uma simulação, a topologia da rede gerada, seu consumo inicial e os resultados são mostrados na interface e podem ser salvos em arquivos de texto. É possível ainda definir onde os logs da simulação devem ser salvos. Na Figura 15, é mostrada a tela principal do simulador. 54 Figura 15 – Tela principal do NetPowerCloudSim. 3.5 TESTES Nesta seção, são apresentados os testes de unidade e de integração realizados no código implementado e a validação dos requisitos funcionais e não funcionais. 3.5.1 Testes de Unidade Os testes de unidade foram realizados com o framework JUnit para verificar a correção do código de cada classe usando valores que levam a condições limítrofes e percorrem todos os caminhos possíveis. Como exemplo, são apresentados os testes realizados na classe TopologiaRede. O método defineTopologia foi testado verificando se os valores dos atributos modificados por ele correspondiam aos valores esperados. Para os testes deste método, foram utilizadas as seguintes quantidades de máquinas físicas: 1, 20, 40, 41, 60, 80, 81, 300, 480, 481, 5760, 5761 e 7000. 55 Para testar o método calculaSwitchAcessoEporta, os ids de máquinas físicas utilizados foram: 0, 1, 20, 39, 40, 60, 79, 479, 480 e 5760. O código gerado pelo JUnit para este método e adaptado para o teste com id igual a 479 é apresentado no Quadro 9. Já os métodos calculaSwitchAgregacaoEporta e calculaModuloSwitchNucleoEporta foram testados com a mesma série de valores de ids de switches de acesso e de agregação, respectivamente: 0, 1, 22, 23, 24, 30 e 100. Quadro 9 – Código gerado pelo JUnit para teste do método calculaSwitchAcessoEporta e adaptado com id de máquina física e resultados esperados. A seguir, na Figura 16, são apresentados os resultados dos testes de unidade da classe TopologiaRede. 56 Figura 16 – Resultados dos testes de unidade da classe TopologiaRede. 3.5.2 Testes de Integração Para verificar a correção dos algoritmos criados para definir a topologia e para reconfigurar a rede, bem como as rotinas de criação e de cálculo do consumo dos componentes da rede, foi implementada uma classe que permite testar o modelo da rede e seu funcionamento interagindo com as classes do CloudSim mas sem iniciar uma simulação. A partir da definição da quantidade de máquinas físicas desejada, esta classe permite realizar testes de integração, criando um datacenter e os demais objetos necessários para compor um cenário de simulação. Com o cenário definido, a classe calcula a topologia e o consumo inicial da rede; desliga as portas sem uso e informa o consumo com esta configuração, além de mostrar os atributos e o estado de cada porta de todos os switches. Para testar a interação dos métodos de reconfiguração da rede da classe GerenciadorRede com os switches e com o datacenter, esta classe permite também ligar e desligar uma máquina física ou um conjunto de máquinas físicas informando, entre outros atributos, o consumo e o estado das portas dos switches que foram modificados. 57 3.5.3 Validação de requisitos A validação foi realizada e homologada em conjunto com os autores do modelo de gerenciamento. Todos os requisitos funcionais e não funcionais listados na seção 3.2 foram contemplados na implementação do NetPowerCloudSim e, portanto, validados. 3.6 SIMULAÇÕES E RESULTADOS A fim de validar as extensões desenvolvidas, foram realizados três experimentos em uma mesma máquina e com diferentes cenários. Os experimentos são compostos por simulações executadas em um microcomputador, cujas características são: processador Intel Core i5-3230M 2,6 GHz; memória RAM de 4 GB DDR3; e sistema operacional Windows 8 de 64 bits. Os três cenários criados para os experimentos possuem os seguintes parâmetros comuns: 1 datacenter; máquinas físicas com 8 núcleos de processamento com capacidade de execução de 2000 MIPS cada, 8 GB de memória RAM, capacidade de armazenamento de 1 TB e largura de banda de 1 Gbps; máquinas virtuais com 2 núcleos de processamento de 1000 MIPS cada, 1 GB de RAM e largura de banda igual a 100 Mbps. Os experimentos realizados e os resultados obtidos são descritos e discutidos a seguir. 3.6.1 Experimento 1 Neste experimento, foi simulado um datacenter com apenas 2 máquinas físicas, 4 máquinas virtuais e 4 aplicações, operando durante 1 hora, com a finalidade de verificar o correto funcionamento das extensões e sua interação com o CloudSim. Foi repetida a simulação quatro vezes: a primeira com a versão original do CloudSim; a segunda com o NetPowerCloudSim sem representar a rede; a terceira com representação da rede, mas sem gerenciamento; e a última com rede gerenciada. Os resultados e os logs de cada simulação foram comparados entre si e com os resultados esperados e foram realizados os ajustes necessários para garantir a correção e a coerência do modelo. Este experimento permitiu avaliar todas as funcionalidades das extensões desenvolvidas, uma vez que, apesar da simplicidade do cenário, acontecem migrações de máquinas virtuais, desligamentos de MFs, reduções e aumentos das taxas de utilização de 58 MFs, e, consequentemente, configurações de velocidade e desligamentos de portas de equipamentos de rede. O Quadro 10 apresenta os resultados desta simulação. Pode-se observar que, como esperado, o consumo do datacenter se manteve constante em todas as repetições da simulação e o consumo da rede foi maior quando não gerenciada. Observa-se também que o consumo da rede possui valor muito próximo ao do consumo do datacenter. Isto acontece porque foi montado um rack com dois switches de acesso para apenas duas máquinas físicas, o que, na prática, não aconteceria. Quadro 10 – Resultados do Experimento 1. Tempo de execução (ms) Consumo inicial da rede (W) Consumo do datacenter (kWh) Consumo da rede (kWh) Consumo total (kWh) Número de migrações de MVs Número de desligamentos de MFs PowerCloudSim NetPowerCloudSim sem rede NetPowerCloudSim sem gerenciamento da rede NetPowerCloudSim com gerenciamento da rede 69 67 77 109 - - 188 124 0,1304 0,1304 0,1304 0,1304 - - 0,1723 0,1076 0,1304 0,1304 0,3027 0,2380 2 2 2 2 1 1 1 1 3.6.2 Experimento 2 Neste experimento, foram simuladas seis horas de operação de um datacenter com 500 MFs, para que a rede fosse composta pelas três camadas da topologia. Foram executadas 2.000 MVs e 2.000 aplicações, de forma que houvesse uma quantidade considerável de migrações de máquinas virtuais e desligamentos de máquinas físicas. A simulação foi repetida três vezes: a primeira sem gerenciamento da rede; a segunda sem gerenciamento, mas desligando as portas sem uso na configuração inicial; e a última com gerenciamento da rede. 59 Os resultados obtidos são apresentados no Quadro 11, no qual se observa que o consumo da rede sem gerenciamento foi de 32,2104 kWh; que, ao desligar as portas sem uso na configuração inicial, houve uma economia de 4,402 kWh (13,66%); e que, com gerenciamento dos equipamentos de rede, a economia foi de 6,8461 kWh (21,25%). Se considerado o consumo total do datacenter (401,6161 kWh), a economia com as portas sem uso desligadas foi de 1,09% e com gerenciamento da rede foi de 1,70%. Quadro 11 – Resultados do Experimento 2. Sem gerenciamento da rede Tempo de execução Consumo inicial da rede (W) Consumo do datacenter (kWh) Consumo da rede (kWh) Consumo total (kWh) Número de migrações de MVs Número de desligamentos de MFs Sem gerenciamento da rede (portas sem uso desligadas) Com gerenciamento da rede 00:02:32.565 00:02:33.359 00:02:37.299 5.444,00 4.700,00 4.700,00 369,4057 369,4057 369,4057 32,2104 27,8084 25,3643 401,6161 397,2141 394,7700 1268 1268 1268 250 250 250 O gráfico da Figura 17 mostra a evolução do consumo da rede durante as 6 horas de operação do datacenter, representando o valor acumulado do consumo em kWh ao final de cada frame da simulação. 60 Figura 17 – Gráfico da evolução do consumo da rede no Experimento 2. Tempo (s) 3.6.3 Experimento 3 Neste experimento, foram simuladas seis horas de operação de um datacenter composto por 5.760 máquinas físicas, 10.000 máquinas virtuais e 10.000 aplicações, com o objetivo de mostrar o funcionamento do simulador representando um datacenter de grande porte e verificar a eficiência do código implementado, bem como o cumprimento do requisito não funcional RN02. Assim como no Experimento 2, a simulação foi repetida três vezes: a primeira sem gerenciamento de rede; a segunda sem gerenciamento, mas desligando as portas sem uso na configuração inicial; e a última com gerenciamento da rede. A partir dos resultados do experimento, apresentados no Quadro 12, é possível observar que o consumo da rede sem gerenciamento foi de 211,06032 kWh; que, desligando as portas sem uso na configuração inicial, houve uma economia de 6,81603 kWh (3,23%); e que, com gerenciamento dos equipamentos de rede, a economia foi de 97,91911 kWh (46,39%). Se considerado o consumo total do datacenter (2.071,77227 kWh), a economia 61 com as portas sem uso desligadas foi de 0,33% e com gerenciamento da rede, de 4,73%. Observa-se ainda que o tempo de execução da simulação com gerenciamento da rede foi de aproximadamente 27 minutos e, portanto, o requisito não funcional RN02 foi atendido. Quadro 12 – Resultados do Experimento 3. Sem gerenciamento da rede Tempo de execução Consumo inicial da rede (W) Consumo do datacenter (kWh) Consumo da rede (kWh) Consumo total (kWh) Número de migrações de MVs Número de desligamentos de MFs Sem gerenciamento da rede (portas sem uso desligadas) Com gerenciamento da rede 00:24:49.597 00:25:28.382 00:27:09.126 3.5672,00 3.4520,00 3.4520,00 1.860,71195 1.860,71195 1.860,71195 211,06032 204,24429 113,14121 2.071,77227 2.064,95624 1.973,85316 12.177 12.177 12.177 4.510 4.510 4.510 O gráfico da Figura 18 mostra a evolução do consumo da rede durante a operação do datacenter. 62 Figura 18 – Gráfico da evolução do consumo da rede no Experimento 3. Tempo (s) 63 4 CONCLUSÕES A Computação em Nuvem é um paradigma que oferece infraestrutura, plataforma de desenvolvimento e aplicativos como serviço, sob demanda e cobrados por uso. Da preocupação com o uso sustentável dos recursos, surge o conceito de Computação em Nuvem Verde, que visa, entre outros objetivos, a economia de energia nos datacenters, nos quais a Nuvem é implementada, por meio de modelos de gerenciamento. Estes modelos podem ser testados e validados através de simulações, modelos analíticos ou testes em ambientes reais. A primeira constitui uma alternativa apropriada, uma vez que os modelos analíticos ou matemáticos podem apresentar baixa acurácia e fidelidade e a realização de testes em ambientes reais pode ser inviável, devido ao alto custo de aquisição e implantação de recursos e à impossibilidade de repetir testes e controlar o tempo. Neste trabalho, foram realizadas extensões ao simulador CloudSim para possibilitar a realização dos testes necessários para a validação de um modelo de gerenciamento de equipamentos de rede legados em um ambiente computacional de nuvem verde. Para representar os equipamentos de rede, foi desenvolvida a classe PowerSwitch, que é estendida por classes que representam switches específicos de cada camada da topologia (acesso, agregação e núcleo) e permite calcular o seu consumo em um determinado momento, bem como a energia consumida durante um frame da simulação. Para representar a topologia da rede, foi criada a classe TopologiaRede, responsável por calcular as quantidades de cada tipo de equipamento que compõe a rede do datacenter a partir do número de máquinas físicas, e suas interligações. Foi implementada ainda a classe GerenciadorTopologia, que contém os atributos e a lógica necessária para ligar e desligar equipamentos de rede e portas, e configurar a velocidade destas, conforme as mudanças de estado das máquinas físicas e com base nas regras e crenças do modelo de gerenciamento. Finalmente, foi estendida a classe PowerDatacenter pela classe NetPowerDatacenter para integrar o modelo de rede ao CloudSim, mediante a interação com os eventos gerados por outras entidades do simulador. Em cada frame da simulação, esta classe acrescenta o consumo da rede ao consumo total do datacenter e informa ao gerenciador da rede as mudanças de estado de cada servidor físico para que este reconfigure os equipamentos de rede conforme as regras. 64 Para facilitar a realização de experimentos, foi desenvolvida uma interface gráfica que permite definir o cenário e repetir simulações com diferentes parâmetros sem a necessidade de modificar o código-fonte. A correção das extensões foi verificada através de testes de unidade e o modelo de rede foi validado de forma independente do CloudSim por meio de uma classe de teste de integração. Finalmente, foram realizados experimentos com diferentes cenários, que demonstraram o correto funcionamento do gerenciamento da rede durante a simulação, bem como o aprimoramento do simulador, acrescentando o consumo da rede ao consumo total do datacenter e permitindo verificar os efeitos da aplicação do modelo de gerenciamento dos equipamentos de rede. Desta forma, a principal contribuição do NetPowerCloudSim foi acrescentar ao CloudSim a capacidade de representar a rede do datacenter e seu gerenciamento, bem como seu consumo, o que viabiliza a realização de experimentos de gerenciamento de equipamentos de rede em nuvem verde para a validação e aprimoramento de estratégias de consolidação de carga de máquinas físicas considerando os efeitos da consolidação do tráfego da rede. Como trabalhos futuros, sugere-se implementar novas funcionalidades ao simulador, como a capacidade de representar equipamentos de rede de tecnologia verde; a criação de políticas de alocação de máquinas virtuais e cargas de trabalho para representar o OTM; a realização do cálculo de violações ao SLA causadas pela ativação e desativação dos equipamentos de rede; e a extensão do modelo para representar e permitir o uso de outras topologias de rede utilizadas em datacenters modernos. Finalmente, propõe-se realizar experimentos para validar a confiabilidade do simulador e a adequada escolha dos parâmetros de configuração, por meio da comparação dos resultados obtidos através de simulações com os obtidos em cenários de nuvem reais. 65 REFERÊNCIAS AMAZON. Amazon Elastic Compute Cloud (Amazon EC2). Seatle, 2013. Disponível em: <http://aws.amazon.com/pt/ec2/>. Acesso em: 06 jun. 2013. ARMBRUST, M. et al. A view of cloud computing. Communications of the ACM, v. 53, n. 4, p. 50-58, 2010. BANKS, J. Introduction to simulation. Simulation Conference Proceedings, 1999 Winter, IEEE, v. 1, p. 7-13, 1999. BELOGLAZOV, A. et al. A taxonomy and survey of energy-efficient data centers and cloud computing systems. Advances in Computers, v. 82, n. 2, p. 47-111, 2011. BELOGLAZOV, A.; BUYYA, R. Optimal Online Deterministic Algorithms and Adaptive Heuristics for Energy and Performance Efficient Dynamic Consolidation of Virtual Machines in Cloud Data Centers, Concurrency and Computation: Practice and Experience (CCPE), v. 24, n. 13, p. 1397-1420, John Wiley & Sons, New York, USA, 2012. BELOGLAZOV, A. Energy-Efficient Management of Virtual Machines in Data Centers for Cloud Computing. Melbourne, 2013. 235 f. Tese (Doutorado em Ciência da Computação). Universidade de Melbourne. BOSE, S. et al. SLA Management in Cloud Computing: A service provider’s perspective. Cloud computing: Principles and Paradigms. Wiley: Hoboken, 2011. BUYYA, R.; YEO, C. S.; VENUGOPAL, S. Market-oriented cloud computing: Vision, hype, and reality for delivering IT services as computing utilities. Proceedings of the 10th IEEE International Conference on High Performance Computing and Communications (HPCC 2008, IEEE CS Press, Los Alamitos, CA, USA), Dalian, set. 2008. BUYYA, R.; BELOGLAZOV, A.; ABAWAJY, J. Energy-efficient management of data center resources for cloud computing: A vision, architectural elements, and open challenges. 2010. CALHEIROS, R. et al. CloudSim: a Toolkit for Modeling and Simulation of Cloud Computing Environments and Evaluation of Resource Provisioning Algorithms. Software: Practice and Experience (SPE), Nova York, v. 41, n. 1, p. 23-50, jan. 2011. CARSON, J. S. Introduction to modeling and simulation. Proceedings of the 36th conference on Winter simulation, p. 9-16, dez. 2004. CELESTI, A. et al. An Approach for the Composition of Generic Cloud-Based Services Using XRI-Based APIs for Enabling New E-Business. International Journal of E-Business Development, v. 3, n. 2, p. 64-74, mai. 2013. CHAVES, S. A.; URIARTE, R. B.; WESTPHALL, C. B. Toward an architecture for monitoring private clouds. IEEE Communications Magazine, v. 49, n. 12, p. 130-137, dez. 2011. 66 FAYAD, M.; SCHMIDT, D. Object-oriented application framework. Communications of the ACM, v. 40, p. 32-38, 1997. FREITAS FILHO, P. J. Introdução à modelagem e Simulação de Sistemas com Aplicações em Arena. Florianópolis: Visual Books, 2008. GARG, S. K.; BUYYA, R. NetworkCloudSim: Modelling Parallel Applications in Cloud Simulations. Fourth IEEE International Conference on Utility and Cloud Computing, p. 105-113, 2011. GERONIMO, G. A. Estratégia para otimizar a Alocação de Máquinas Virtuais em Nuvens Verdes. Florianópolis, 2012. Dissertação (Mestrado em Ciências da Computação). Universidade Federal de Santa Catarina. GOOGLE. Google Apps for business. Mountain View, 2013. Disponível em: <http://www.google.com/intx/pt-BR/enterprise/apps/business/>. Acesso em: 06 jun. 2013. JARARWEH, Y. et al. TeachCloud: A Cloud Computing Educational Toolkit. The 1st International IBM Cloud Academy Conference, North Carolina, 2012. MELL, P.; GRANCE, T. The NIST definition of cloud computing (draft). NIST special publication, v. 800, p. 145, 2011. MENASCE, D. A., ALMEIDA, V. A., DOWDY, L. W. Performance by design: computer capacity planning by example. New Jersey: Prentice Hall PTR, 2004. PFLEEGER, S. L. Engenharia de software: teoria e prática. 2 ed. São Paulo: Prentice Hall, 2004. MICROSOFT.Windows Azure. Redmond, 2013. Disponível em: <http://www.windowsazure.com/pt-br/>. Acesso em: 06 jun. 2013. SÁ, T. T. CloudReports: A simulation tool for Cloud Computing environments. 2013. Disponível em: <https://github.com/thiagotts/CloudReports>. Acesso em: 20 jun. 2013. SHANNON, R. E. Introduction to the art and science of simulation. Simulation Conference Proceedings, IEEE, p. 7-14, 1998. SUN MICROSYSTEMS. Introduction to Cloud Computing Architecture. 2009. Disponível em: <https://java.net/jira/secure/attachment/29265/CloudComputing.pdf>. Acesso em: 06 jun. 2013. TAURION, C. Cloud Computing: Computação em Nuvem: Transformando o mundo da Tecnologia da Informação. Rio de Janeiro: Brasport, 2009. VILLARREAL, S.; WESTPHALL C. B. Otimização de Nuvem Verde Mediante o Gerenciamento de Equipamentos de Rede Legados. International Conference on Networking, Sevilha, jan. 2013. 67 VOORSLUYS, W.; BROBERG, J.; BUYYA, R. Introducing to cloud computing. Cloud computing: Principles and Paradigms. Wiley: Hoboken, 2011. WERNER, J. et al. Aperfeiçoando a gerência de recursos para nuvens verdes. 2012. WERNER, J. Uma Abordagem para Alocação de Máquinas Virtuais em Ambientes de Computação em Nuvem Verde. Florianópolis, 2011. Dissertação (Mestrado em Ciências da Computação). Universidade Federal de Santa Catarina. WESTPHALL C. B; VILLARREAL, S. Princípios e Tendências em Green Cloud Computing. Revista Eletrônica de Sistemas de Informação, v. 12, n. 1, p. 1-19, jan-mai 2013. 68 APÊNDICE A – Detalhamento dos Casos de Uso Quadro 13 – Detalhamento do caso de uso UC01. UC01 – Definir cenário Descrição Ator Pré-condição Pós-condição Fluxo principal Fluxo alternativo 1 Fluxo alternativo 2 São definidos os valores das variáveis que compõem o cenário da simulação. Usuário. Não existe. Cenário definido. 1. O usuário informa as características das máquinas físicas. 2. O usuário informa as características das máquinas virtuais. 3. O usuário informa as características das aplicações. 4. O usuário indica o tipo de gerenciamento da rede. 5. O usuário informa o tempo de operação do datacenter a ser simulado. 1. O usuário modifica as crenças do modelo (consumo base de cada tipo de switch e consumo por tipo de porta). 1. Nos itens 1, 2 ou 3, o usuário digita um valor inválido. 2. A aplicação informa o erro. 3. A aplicação restaura o valor padrão do campo de texto. Quadro 14 – Detalhamento do caso de uso UC02. UC02 – Iniciar simulação Descrição Ator Pré-condição Pós-condição Fluxo principal Os dados do cenário definido são passados para o simulador e a simulação é iniciada. Usuário. Cenário definido. Simulação iniciada. 1. O usuário pressiona o botão para iniciar a simulação. 2. A aplicação transfere os dados do cenário definido pelo usuário para o simulador. 3. A aplicação cria o cenário (UC03) e a topologia (UC04). 4. A simulação inicia. 69 Quadro 15 – Detalhamento do caso de uso UC03. UC03 – Criar cenário Descrição Ator Pré-condição Pós-condição Fluxo principal Fluxo alternativo O datacenter, a topologia da rede e as aplicações são criados, de acordo com o cenário definido. Usuário. Cenário definido. Cenário criado. 1. A aplicação cria o broker. 2. A aplicação cria o datacenter. 3. A aplicação cria as máquinas físicas. 4. A aplicação cria as máquinas virtuais. 5. A aplicação cria as aplicações. 6. A aplicação cria a topologia de rede (UC04). 7. A aplicação calcula o consumo da rede com todas as portas ligadas. 8. A aplicação informa o consumo da rede. 1. Após o item 7, a aplicação desliga as portas sem uso dos equipamentos de rede. 2. A aplicação informa o consumo da rede. 70 Quadro 16 – Detalhamento do caso de uso UC04. UC04 – Criar topologia Descrição A topologia de rede é criada, de acordo com o cenário definido. Usuário. Datacenter e máquinas físicas criados. Topologia definida e criada. 1. A aplicação calcula a quantidade de racks de acordo com o número de máquinas físicas. 2. A aplicação calcula a quantidade de switches de acesso de acordo com o número de racks. 3. A aplicação calcula a quantidade de switches de agregação de acordo com o número de switches de acesso. 4. A aplicação calcula a quantidade de módulos dos switches de núcleo de acordo com a quantidade de switches de agregação. 5. A aplicação cria uma lista de switches de acesso. 6. A aplicação cria os switches de acesso e os adiciona à lista. 1. Após o item 6, a aplicação cria os switches de agregação (UC05). Ator Pré-condição Pós-condição Fluxo principal Fluxo alternativo Quadro 17 – Detalhamento do caso de uso UC05. UC05 – Criar switches de Agregação Descrição Ator Pré-condição Pós-condição Fluxo principal Fluxo alternativo São criados os switches de camada de agregação. Usuário. Datacenter, máquinas físicas e switches de Acesso criados. Switches de agregação criados. 1. A aplicação cria uma lista de switches de agregação. 2. A aplicação cria os switches de agregação e os adiciona à lista. 1. Após o item 6, a aplicação cria os switches de núcleo (UC06). 71 Quadro 18 – Detalhamento do caso de uso UC06. UC06 – Criar switches de Núcleo Descrição Ator Pré-condição Pós-condição Fluxo principal São criados os switches de camada de núcleo. Usuário. Datacenter, máquinas físicas e switches de acesso e de agregação criados. Switches de núcleo criados. 1. A aplicação cria uma lista de switches de Núcleo. 2. A aplicação cria os switches de Núcleo e os adiciona à lista. Quadro 19 – Detalhamento do caso de uso UC07. UC07 – Cancelar simulação Descrição Ator Pré-condição Pós-condição Fluxo principal A simulação em execução é cancelada. Usuário. Simulação iniciada. Simulação cancelada. 1. O usuário pressiona o botão para cancelar a execução da simulação. 2. A aplicação cancela a simulação. 3. A aplicação informa que a simulação foi cancelada. 4. A aplicação mostra os resultados parciais. 72 Quadro 20 – Detalhamento do caso de uso UC08. UC08 – Salvar resultados Descrição Ator Pré-condição Pós-condição Fluxo principal Fluxo alternativo Os resultados da simulação são salvos em um arquivo de texto. Usuário. Simulação finalizada corretamente. Arquivo salvo. 1. O usuário pressiona o botão para salvar os resultados da simulação. 2. A aplicação mostra a janela de pastas do sistema. 3. O usuário seleciona o local para salvar o arquivo. 4. O usuário informa o nome do arquivo. 5. A aplicação grava o arquivo no disco. 1. Nos itens 2, 3 ou 4, o usuário cancela a operação. Quadro 21 – Detalhamento do caso de uso UC09. UC09 – Salvar logs Descrição Ator Pré-condição Pós-condição Fluxo principal Os logs da simulação são salvos em um arquivo de texto. Usuário. Simulação iniciada. Arquivo salvo. 1. O usuário pressiona o botão para selecionar o diretório em que os logs da simulação devem ser salvos. 2. A aplicação mostra a janela de pastas do sistema. 3. O usuário seleciona o local para salvar o arquivo. 4. O usuário informa o nome do arquivo. 5. A aplicação grava os logs no arquivo durante a simulação. 73 Quadro 22 – Detalhamento do caso de uso UC10. UC10 – Ligar porta de switch de acesso Descrição Ator Pré-condição Pós-condição Fluxo principal Fluxo alternativo É ligada a porta do switch de acesso correspondente a uma máquina física que foi ligada. CloudSim. Porta do switch de acesso desligada. Porta do switch de acesso ligada e configuração da rede ajustada conforme as regras. 1. A aplicação calcula o número do switch e da porta correspondente à máquina física. 2. A aplicação verifica se o switch está ligado. 3. A aplicação liga a porta do switch. 4. A aplicação atualiza o estado da porta com o valor de velocidade padrão. 5. A aplicação verifica se deve aumentar a velocidade das portas de uplink. 6. A aplicação atualiza o valor do consumo atual do switch. 1. No item 2, se o switch está desligado, a aplicação liga o switch. 2. A aplicação liga as portas de uplink e a porta do switch agregação correspondente. 3. A aplicação verifica se deve modificar a configuração dos switches de agregação e de núcleo. 74 Quadro 23 – Detalhamento do caso de uso UC11. UC011 – Desligar porta de switch de acesso Descrição É desligada a porta do switch de acesso correspondente a uma máquina física que foi desligada. Ator CloudSim. Pré-condição Porta do switch de acesso ligada. Pós-condição Porta do switch de acesso desligada e configuração da topologia ajustada conforme as regras. Fluxo principal 1. A aplicação calcula o número do switch e da porta correspondente à máquina física. 2. A aplicação desliga a porta do switch. 3. A aplicação verifica se ainda há alguma porta ligada. 4. A aplicação atualiza o estado da porta com valor zero. 5. A aplicação verifica se deve reduzir a velocidade das portas de uplink. 6. A aplicação atualiza o valor do consumo atual do switch. Fluxo alternativo 1. No item 3, se não há portas ligadas, a aplicação desliga as portas de uplink, a porta do switch de agregação correspondente e o próprio switch. 2. A aplicação verifica se deve modificar a configuração dos switches de agregação e de núcleo. 75 Quadro 24 – Detalhamento do caso de uso UC12. UC12 – Reduzir velocidade de porta de switch de acesso Descrição É reduzida a velocidade da porta do switch correspondente a uma máquina física subutilizada. Ator CloudSim. Pré-condição Porta do switch ligada com velocidade Giga Ethernet e conectada a máquina física com utilização menor ou igual a 30%. Pós-condição Velocidade da porta do switch reduzida e configuração da rede ajustada conforme as regras. Fluxo principal 1. A aplicação calcula o número do switch e da porta correspondente à máquina física. 2. A aplicação chama o método para reduzir a velocidade da porta. 3. A aplicação atualiza o estado da porta para Fast Ethernet. 4. A aplicação atualiza o valor do consumo atual do switch. Fluxo Alternativo 1. Após o item 4, a aplicação verifica se deve modificar a configuração dos switches de agregação e de núcleo. 76 Quadro 25 – Detalhamento do caso de uso UC13. UC013 – Aumentar velocidade de porta de switch de acesso Descrição É aumentada a velocidade da porta do switch correspondente a uma máquina física que voltou ao nível normal de utilização. Ator CloudSim. Pré-condição Porta do switch ligada com velocidade Fast Ethernet e conectada a máquina física com utilização maior que 30%. Pós-condição Velocidade da porta do switch aumentada e configuração da rede ajustada conforme as regras. Fluxo principal 1. A aplicação calcula o número do switch e da porta correspondente à máquina física. 2. A aplicação chama o método para aumentar a velocidade da porta. 3. A aplicação atualiza o estado da porta Giga Ethernet. 4. A aplicação atualiza o valor do consumo atual do switch. Fluxo alternativo 1. Após o item 4, a aplicação verifica se deve modificar a configuração dos switches de agregação e de núcleo. Quadro 26 – Detalhamento do caso de uso UC14. UC14 – Calcular o consumo da rede no frame Descrição A aplicação calcula a energia consumida pela rede durante um frame da simulação. Ator CloudSim. Pré-condição Simulação iniciada e topologia criada. Pós-condição Consumo da rede durante o frame calculado. Fluxo principal 1. A aplicação calcula o consumo de cada switch durante o frame. 2. A aplicação acumula os consumos em uma única variável. 3. A aplicação informa o consumo calculado. 4. A aplicação atualiza o consumo total da rede com o valor do consumo no frame.