Os experimentos realizados nesta tese baseiam-se em simulações, utilizando o framework de simulação CloudSim versão 3.0.1, proposto por Calheiros et al. (2011), conforme apresentado na Seção 2.7. A figura 6.1 ilustra o ambiente de teste considerado nas avaliações
de desempenho apresentadas neste Capítulo. A nuvem adotada na simulação considerou a implementação de dois modelos: uma nuvem privada e uma nuvem híbrida (combinação da nuvem privada e da nuvem pública). No modelo híbrido, as requisições são direcionadas à nuvem pública contratada, quando seus recursos privados são insuficientes para atender tal demanda, proporcionando um melhor desempenho aos serviços quando comparado aos cenários onde se utiliza apenas uma nuvem privada. Conforme descrito na Seção 5.3.2, o modelo de nuvem híbrida implementado possibilita que seja parametrizado pelo usuário, antes da simulação iniciar, um percentual de consumo limite dos recursos do data center privado, que se atingido, o Broker passa a encaminhar as requisições para a nuvem pública. Para os experimentos que consideraram o modelo de nuvem híbrido, apresentados na Seção 6.6, esse percentual de consumo limite dos recursos foi parametrizado em 80%. Com a adoção desses diferentes modelos de nuvem é possível avaliar e comparar o impacto das rajadas no desempenho dos serviços quando submetidos a uma nuvem privada ou a uma nuvem híbrida.
Os modelos de nuvem considerados, possuem um data center composto por servidores (hosts) físicos e máquinas virtuais (VM - Virtual Machine). A Tabela 6.1 descreve a configuração física de cada um dos servidores e máquinas virtuais dos provedores de nuvens considerados na execução dos experimentos.
Tabela 6.1 – Configuração dos Servidores dos Provedores de Nuvem
Nuvem Privada Nuvem Pública
Servidor VM Servidor VM
Processador Intel Xeon 6 cores 2.66GHz 1 core 2.66GHz Intel Xeon 8 cores 2.6 Ghz 1 core 2.6 GHz Capacidade de
Processamento (Mips/s)
7.000 MIPs/core 7.000 Mips 10.000 MIPs/core 7.000 Mips
Memória
Principal 24GB 4GB 32GB 4GB
Disco 144 GB 24GB 2TB 96 GB
Sistema
Operacional Ubuntu 14.04 Ubuntu 14.10
Cada um dos data centers, privado e público, considerado neste estudo, é composto por 10 servidores (hosts) físicos homogêneos. Da mesma forma como os servidores físicos, no data
center privado, são instanciadas 40 máquinas virtuais homogêneas e no data center público são
CAPÍTULO 6 – IMPACTO DAS RAJADAS NO DESEMPENHO DOS SERVIÇOS 85 (Bhatt e Patel, 2012) (Deka e Prashanta, 2014). Para identificar quais VMs pertencem à nuvem
privada e à nuvem pública, são atribuídas faixas de numeração diferentes para identifica-las, ou seja, as VMs da nuvem privada são identificadas com uma numeração de 1 a 40 e as VMs da nuvem pública de 1301 a 1360. São considerados também cinco serviços Web distribuídos de forma aleatória entre as VMs, onde cada VM é responsável pela execução de dois serviços Web distintos.
Se consumo de recursos acima de 80%, encaminha requisições para a nuvem pública.
Nuvem Privada QBROKER Monitores Nuvem Pública Virtualização (Xen) 60 Máquinas Virtuais 10 Servidores ... ... Virtualização (Xen) 40 Máquinas Virtuais 10 Servidores ... ... . .
. Req. Tempo Real
100 Clientes
Figura 6.1 - Ambiente de Testes.
A política de alocação de máquinas virtuais adotada é a Space-shared, assim a máquina virtual ocupa uma entidade de processamento ou core, durante todo o tempo de simulação. Para alocar as cargas de trabalho nas máquinas virtuais, também é utilizada a política Space-shared, ou seja, uma vez que uma requisição começa a ser processada, não há possibilidade de preempção.
Para todos os experimentos realizados neste estudo, considera-se uma quantidade de 100 clientes concorrentes responsáveis pela submissão das requisições de serviços distintos, durante um tempo de simulação de 5400 unidades de tempo de simulação, a qual equivale a um intervalo de amostra de simulação (no caso do CloudSim representada em segundos). Da
mesma forma que para as máquinas virtuais, o serviço da requisição de cada cliente é definido de forma aleatória entre os cinco serviços Web disponíveis.
Quanto às configurações referentes às latências de rede, são definidas latências distintas entre cada cliente e Broker, atribuídas de forma aleatória entre 5 e 500ms, representando um cenário onde vários clientes concorrentes acessam a nuvem, em posições geográficas distintas. No modelo considerado, o Broker está localizado junto ao provedor de nuvem privada e, portanto, a latência de rede para este caso é considerada nula. A latência de rede entre Broker e provedor de nuvem pública é definida também de forma aleatória entre 20 e 80 ms. Para o caso de nuvem híbrida, foi considerado que a nuvem pública está interconectada ao Broker, através de uma conexão dedicada, com latências mais baixas.
Cada cliente submete requisições ao Broker usando o modelo de submissão de requisições em tempo real, onde o processo de envio ocorre durante todo o tempo de simulação. O modelo de carga de trabalho considera situações em que o processo de chegada das requisições e/ou demandas de serviços chegam ou não em forma de rajadas, sendo que no primeiro caso, as rajadas com diferentes variabilidades e intensidades são modeladas usando o Processo de Chegada Markoviano (MAP – Markovian Arrival Process). A metodologia empregada para parametrizar os modelos MAPs considerados neste trabalho, é descrita na Seção 6.3. Na situação sem rajadas, os intervalos de chegadas e demandas de serviços são gerados seguindo uma distribuição exponencial, com médias de sete segundos, a mesma média considerada na parametrização dos modelos MAPs, e são melhor detalhados na Seção 6.5. A configuração dos think times entre requisições sucessivas, para todos os experimentos, considera a opção implementada na arquitetura desenvolvida, apresentada no Capítulo 5, em que o cliente envia a próxima requisição apenas após aguardar um intervalo de time (think time) contado a partir do recebimento da resposta completa da requisição prévia.