Virtualização de Sistemas Distribuídos

Prévia do material em texto

Prof. Luiz Fernando Bittencourt IC - UNICAMP 
MO809L 
Tópicos em Sistemas Distribuídos 
1° semestre, 2013 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Virtualização 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Virtualização 
•  Threads e processos podem ser vistos como modo de fazer 
mais coisas ao mesmo tempo. 
•  Porções de programas que parecem ser executados simultaneamente. 
•  Computador monoprocessado: somente uma ilusão de paralelismo 
através de chaveamento rápido entre threads e processos. 
• Capacidade de “fingir que há mais CPUs” pode ser estendida 
a outros tipos de recursos. 
•  Virtualização de recursos. 
• Utilizada há muito tempo. 
• Renovado interesso à medida que sistemas (distribuídos) 
tornaram-se mais comuns e complexos. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Virtualização 
• Sistema de computadores: interface de programação para 
software de alto nível. 
• Diferentes interfaces. 
•  Conjunto básico de instruções oferecido por uma CPU. 
•  Conjunto de interfaces de programação de middlewares. 
• Virtualização: estender ou substituir uma interface de modo a 
imitar o comportamento de um outro sistema. 
•  Figura 45. 
 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Virtualização 
• Década de 70: permitir que softwares executassem em 
hardwares caros de mainframes. 
• Software não incluía somente aplicações, mas também 
sistemas operacionais para os quais havia sido 
desenvolvido. 
• Aplicada com sucesso em mainframes IBM 370 e 
sucessores. 
•  Ofereciam máquina virtual para diferentes SOs. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Virtualização 
• Hardware mais barato. 
• Computadores mais potentes. 
• Menor quantidade de SOs. 
• Virtualização deixava de ser importante. 
•  Final da década de 90, virtualização voltou a se tornar 
importante. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Virtualização 
• Ajuda a reduzir a quantidade necessária de plataformas de 
hardware para atender softwares com necessidades 
diferentes. 
•  Virtualização deixa que cada aplicação execute em sua própria 
máquina virtual, possivelmente incluindo bibliotecas e o sistema 
operacional. 
• Proporciona alto grau de portabilidade e flexibilidade. 
• Por exemplo, gerenciamento mais fácil de replicação. 
•  Servidores podem ser copiados, incluindo ambiente, dinamicamente. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Virtualização - motivação 
• Server Consolidation: consolidar cargas de trabalho de 
múltiplas máquinas subutilizadas em quantidade menor de 
máquinas para economizar hardware, gerência, 
administração. 
• Application consolidation: aplicações legadas podem 
necessitar de máquinas virtualizadas para rodar em 
máquinas mais novas. 
• Sandboxing: isolamento de ambientes para execução de 
aplicações não confiáveis. 
• Múltiplos ambientes de execução: criar múltiplos ambientes 
independentes com garantia de recursos para prover QoS. 
 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Virtualização - motivação 
• Hardware virtual: drivers SCSI virtuais, adaptadores ethernet 
virtuais, switches e hubs virtuais... 
• Executar múltiplos SOs simultaneamente. 
• Depuração: pode permitir depuração de aplicações de 
usuário sem preocupação com problemas de interrupção de 
outras aplicações/serviços. 
• Migração: facilita migração de software. 
• Permite empacotar aplicações junto com ambiente de 
execução. 
•  Teste: facilita a produção de cenários de teste arbitrários que 
são difíceis de produzir na prática. 
 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Abstração e virtualização 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Abstração e virtualização 
• Abstração com interfaces bem definidas ajuda no 
desenvolvimento e manutenção. 
• Escondem detalhes de implementação de nível mais baixo. 
• Ex.: SO abstrai sistema de arquivos e endereçamento. 
•  Disco aparece como um conjunto de arquivos de tamanhos variados, 
escondendo setores e trilhas. 
•  Programadores manipulam arquivos pelos nomes. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Abstração e virtualização 
• Arquitetura do conjunto de instruções (ISA) é um bom 
exemplo das vantagens de interfaces bem definidas. 
•  Intel e AMD implementam em seus processadores um 
conjunto de instruções x86, enquanto softwares são 
desenvolvidos para compilar e executar nesse conjunto de 
instruções. 
•  Limitações no uso: por exemplo, binários compilados estão 
amarrados à arquitetura-alvo; impede interoperabilidade. 
•  Limitação importante em computadores heterogêneos conectado por 
rede. 
•  Mapeamento de interface e recursos visíveis para sistema real 
potencialmente diferente pode contornar esse problema. 
•  Sistema virtual apresentado como outro sistema, ou múltiplos 
sistemas. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Abstração e virtualização 
• Ao contrário da abstração, a virtualização não 
necessariamente objetiva simplificar ou esconder detalhes. 
• Ex.: virtualização de disco transforma um disco grande único 
em dois virtuais menores, cada um com seu conjunto de 
trilhas e setores. 
• Software de virtualização utiliza a abstração de arquivos 
como um passo intermediário para o mapeamento entre 
disco real e virtual. 
• Escrita no disco virtual é convertida em uma escrita de 
arquivo no disco real. 
• Nível de detalhes fornecido na interface de disco virtual é o 
mesmo do disco real; não há abstração. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Abstração e virtualização 
James E. Smith, Ravi Nair. The Architecture of Virtual Machines. IEEE Computer. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de máquinas virtuais 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de Máquinas Virtuais 
• Para discutir VMs é preciso entender arquitetura de sistemas 
de forma geral. 
• Arquitetura refere-se a uma especificação formal de 
interfaces do sistema, incluindo comportamento lógico dos 
recursos gerenciados através da interface. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de Máquinas Virtuais 
• Em geral, sistemas de computadores oferecem 4 tipos 
diferentes de interfaces em 4 níveis diferentes: 
•  Entre hardware e software: instruções de máquina que podem ser 
invocadas por qualquer pograma. 
•  Entre hardware e software: instruções de máquina que podem ser 
invocadas somente por programas privilegiados, como o sistema 
operacional. 
•  Chamadas de sistema: oferecidas por um sistema operacional. 
•  Chamadas de biblioteca: conjunto conhecido como interface de 
aplicação de programação (API). Em muitos casos, ocultam chamadas 
de sistema. 
•  Fig. 46. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de Máquinas Virtuais 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de Máquinas Virtuais 
•  Instruction Set Architecture (ISA): 
•  Divisão entre hardware e software (3) e (4). 
•  ISA de usuário: aspectos visíveis às aplicações (4). 
•  ISA de sistema: visível pelo SO, gerenciar o hardware (3). 
•  ISA de sistema é um superconjunto da ISA do usuário. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de Máquinas Virtuais 
• Application Binary Interface (IBA): 
•  Fornece acesso aos recursos de hardware disponíveis através do ISA 
de usuário (4) e chamadas de sistema (2). 
•  Não inclui instruções do sistema; programas interagem com o 
hardware indiretamente invocando serviços do SO pela interface de 
chamadas de sistema. 
•  Chamadas de sistema: meio do SO realizar operações no hardware no 
lugar do programa de usuário, verificando autenticação / segurança. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de Máquinas Virtuais 
• Application Programming Interface (API): 
•  Fornece acesso aos recursos de hardware através do ISA de usuário 
(4) e chamadas de bibliotecas de alto nível (1). 
•  Chamadas de sistema geralmente são feitas através de bibliotecas. 
•  Usar uma API permite portabilidade através de recompilaçãoem 
sistemas que suportem a mesma API. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de Máquinas Virtuais 
• Do ponto de vista do processo, uma máquina é um espaço 
lógico de memória atribuído ao processo em conjunto com 
instruções de nível de usuário e registradores que permitem 
a execução do código do processo. 
• E/S é visível somente através do sistema operacional através 
de chamadas de sistema. 
• ABI define uma máquina como vista pelos processos. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de Máquinas Virtuais 
• Do ponto de vista do SO e das aplicações, o sistema é um 
ambiente que roda sobre uma máquina subjacente e é 
capaz de suportar múltiplos processos simultaneamente. 
• Processos compartilham sistema de arquivos e outros 
dispositivos de E/S. 
• Sistema sobrevive às idas e vindas dos processos. 
• Aloca memória real e recursos de E/S aos processos e 
controla acesso. 
• Da perspectiva do sistema, o hardware define a máquina; o 
ISA fornece interface entre sistema e a máquina. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de Máquinas Virtuais 
• Da mesma forma que há pontos de vista de máquina para 
processos e para sistemas, também os há para máquinas 
virtuais. 
• Uma máquina virtual de processo é uma plataforma que 
executa apenas um processo. 
•  Existe somente para suportar o processo. 
•  Criado quando o processo é criado. 
•  Termina quando processo termina. 
• Uma máquina virtual de sistema fornece um ambiente de 
sistema completo e persistente que suporta um sistema 
operacional com seu conjunto de processos de usuário. 
•  Fornece ao sistema operacional convidado acesso a recursos de 
hardware virtuais (rede, E/S etc.) 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de Máquinas Virtuais 
• Processo ou sistema rodando numa VM é o convidado, 
enquanto a plataforma que suporta a VM é o hospedeiro. 
• Virtualização pode ocorrer de dois modos. 
•  Virtualização de processo, através de runtime software. 
•  Virtualiação de máquina, através de virtual machine monitor. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de Máquinas Virtuais 
• Virtualização pode ocorrer de dois modos. 
•  Sistema de execução com conjunto de instruções abstrato para 
executar aplicações. 
•  Instruções interpretadas (p. ex. Java). 
•  Emulação (Wine) – necessário imitar comportamento de chamadas de 
sistema (não trivial). 
•  Chamada de máquina virtual de processo (Smith e Nair) / runtime software. 
•  Fornecer um sistema que seja uma camada que protege 
completamente o hardware original, mas que oferece como interface o 
conjunto de instruções completo do mesmo (ou de outro) hardware. 
•  Pode ser oferecida simultaneamente a programas diferentes. 
•  Vários sistemas operacionais executando independente e concorrentemente 
na mesma plataforma. 
•  Camada chamada de Virtual Machine Monitor – VMM (VMWare, Xen). 
•  Fig. 47 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de Máquinas Virtuais 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de Máquinas Virtuais 
• VM de processo: software 
de virtualização está no nível 
de ABI ou API. 
• Emula instruções de nível de 
usuário e chamadas de 
sistema. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de Máquinas Virtuais 
• VM de sistema: software de 
virtualização está entre o 
hardware e o software 
convidado. 
• Se mostra como ISA 
potencialmente diferente do 
hospedeiro. 
• VMM muitas vezes tem o 
papel de fornecer recursos 
de hardware virtualizados ao 
invés de tradução de ISA 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Arquiteturas de Máquinas Virtuais 
•  Importante para confiabilidade e segurança. 
•  Isolamento de uma aplicação completa e seu ambiente. 
•  Falha não afeta outras VMs. 
• Melhor portabilidade. 
•  Desacopla hardware e software. 
•  Permite mover ambiente completo. 
• Máquinas paralelas 
•  Permite consolidação de servidores. 
•  Maximizar utilização. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Alguns conceitos em máquinas virtuais 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas Virtuais 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais 
• Simulação completa de um sistema em outra, instrução por 
instrução, é técnica conhecida há décadas. 
•  Por exemplo, aplicação de propósito específico para um computador X 
cujo hardware ainda está em desenvolvimento. 
•  Simulador para X (processador, memória, periféricos) que rode em 
máquina de propósito geral G. 
•  Programas que rodam em G poderão rodar em X com mesmos 
resultados (exceto para questões de tempo). 
•  Programas podem usar espaço de memória simulado, dispositivos 
simulados, executar instruções na máquina simulada. 
•  Simulador provê uma camada de software que filtra e protege os 
recursos da máquina G, evitando que sejam utilizados de forma 
indevida pelos programas da máquina X. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais 
• Múltiplos programas: 
•  Múltiplas cópias do simulador. 
•  Simulador capaz de dividir o tempo entre aplicações. 
•  Ambos os casos resultam numa ilusão de múltiplas cópias da interface 
de hardware-software da máquina X em G. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais 
• X e G arbitrários 
•  Software de simulação pode ser muito complexo e piorar desempenho 
de forma impraticável. 
•  Inicialmente mais utilizado para desenvolvimento de software. 
• X e G idênticos 
•  Muitas cópias da interface hardware-software de G em G. 
•  Cada usuário com sua cópia privada da máquina G. 
•  Escolha do SO para rodar em sua máquina privada. 
•  Desenvolver/depurar seu próprio SO. 
•  Simuladores não interferem um no outro. 
•  Slowdown menor que para X diferente de G. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais 
• Desenvolvimento de simuladores mais eficientes de múltiplas 
cópias de uma máquina sobre seu próprio hardware. 
•  Parte do software para máquinas simuladas roda sobre o hardware, 
sem interpretação de software. 
•  Chamados de Virtual Machine Systems. 
•  Máquinas simuladas chamadas de máquinas virtuais (VMs). 
•  Software simulador: virtual machine monitor (VMM). 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais 
• VMM transforma interface única da máquina na ilusão de 
muitas máquinas. 
• Cada interface (máquina virtual) é uma réplica eficiente do 
sistema de computação original. 
•  Com todas as instruções de processador (privilegiadas e não 
privilegiadas). 
•  Com todos os recursos dos sistema (memória e E/S). 
• Diversas máquinas virtuais em paralelo permitem diversos 
SOs (núcleos privilegiados) concorrentemente. 
• Máquinas virtuais fornecem réplicas isoladas de um 
ambiente em um sistema de computação. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais 
• Recursos extras (CPU, memória) são usados pelo VMM. 
•  Potencial queda na vazão do sistema. 
• Manter estado do processador virtual. 
•  Integridade de todos os registradores visíveis, bits de estado e 
memória reservada (controle de interrupção) devem ser preservados. 
•  Captura e simulação de instruções privilegiadas. 
•  Suporte a paginação em máquinas virtuais. 
•  Faltas de página. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais 
• Podem ser utilizadas para manter sistemas antigos enquanto 
novos sistemas são testados e programas são convertidos. 
• Adicionar novos dispositivos sem alterar SO da máquina 
virtual, que já suporta o dispositivo virtualizado. 
•  Teste de softwares de rede. 
• Confiabilidade de software através de isolamento. 
•  VMM é provavelmente correta: pequena e verificável. 
• Segurança de dados. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais 
•  Uma variedade de mecanismos e técnicas para desacoplar 
a arquitetura e o comportamento de hardware e software 
percebido pelo usuário de suaimplementação física. 
• VMM: camada entre ambientes de software e o hardware 
físico que é programável, transparente ao software acima 
dela, e usa eficientemente o hardware abaixo dela. 
• De forma similar, virtualização de rede e armazenamento 
também fornecem capacidade de multiplexar, em um único 
recurso físico, vários sistemas virtuais isolados uns dos 
outros. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais 
• Contraste com a abordagem comum de incluir camadas mais 
abstratas sobre a camada de abstração mais alta existente. 
• Na última década máquinas virtuais voltaram a receber 
atenção. 
•  Anteriormente aplicadas a plataformas de grande porte, agora atingem 
plataformas pessoais. 
•  Advento do VMWare (1998) e Virtual PC (1997). 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais 
• Atualmente servidores são muito mais baratos e poderosos 
que no passado. 
• Mas: custo total da posse inclui manutenção, suporte e 
administração, assim como custos associados a brechas de 
segurança e falhas. 
• Consolidação de servidores ainda é um motivador importante 
para uso de máquinas virtuais. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais 
• Uma máquina virtual pode suportar processos individuais ou 
sistemas completos, dependendo do nível de abstração onde 
a virtualização ocorre. 
• Algumas VMs suportam uso flexível de hardware e 
isolamento de software, outras traduzem conjuntos de 
instruções. 
• Variedade de arquiteturas de máquinas virtuais. 
•  Máquinas virtuais de processo e de sistema. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de processo 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de processo 
•  Fornecem ambiente virtual ABI ou API para aplicações de 
usuário. 
• Sistemas multiprogramados: 
•  VM de processo mais comum (muitas vezes desconsiderada como 
VM). 
•  Muitos sistemas operacionais suportam múltiplos processos de usuário 
simultâneamente através de multiprogramação. 
•  Processo tem ilusão de ter uma máquina completa para si. 
•  Cada processo tem seu próprio espaço de endereçamento, 
registradores e estrutura de arquivos. 
•  SO divide hardware por tempo, gerenciando os recursos disponíveis. 
•  Consequentemente, SO fornece uma VM de processo replicada para 
cada aplicação executada concorrentemente. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de processo 
• Emuladores e tradutores binários dinâmicos: 
•  Suportar binários de programas compilados para outra arquitetura. 
•  Modo direto: interpretação (fetch, decode, emulate) das instruções do 
convidado. 
•  Pode ser relativamente lento, necessitando muitas instruções do hospedeiro 
para cada instrução interpretada. 
•  Melhoria de desempenho: tradutor binário dinâmico. 
•  Traduz instruções em blocos ao invés de uma a uma e salva em cache para 
reuso. 
•  Utilização repetida de conjunto de instruções amortiza overhead maior na 
tradução. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de processo 
• Same-ISA binary optimizer 
•  Mesmo conjunto de instruções do hospedeiro e convidado. 
•  Propósito: realizar otimização de código durante tradução. 
•  Utiliza informações coletadas durante a interpretação para otimizar o 
binário on-the-fly. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de processo 
• High-level-language VMs 
•  Portabilidade entre plataformas é desejável em VMs de processo. 
•  Esforço de desenvolvimento caso a caso. 
•  Portabilidade total entre plataformas pode ser alcançada 
desenvolvendo-se uma VM de processo como parte de um ambiente 
de desenvolvimento de aplicações em linguagem de alto nível. 
•  HLL VM resultante não corresponde diretamente a nenhuma 
plataforma, mas é desenhada para facilitar portabilidade. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de processo 
• High-level-language VMs 
•  Portabilidade entre plataformas é desejável em VMs de processo. 
•  Esforço de desenvolvimento caso a caso. 
•  Portabilidade total entre plataformas pode ser alcançada 
desenvolvendo-se uma VM de processo como parte de um ambiente 
de desenvolvimento de aplicações em linguagem de alto nível. 
•  HLL VM resultante não corresponde diretamente a nenhuma 
plataforma, mas é desenhada para facilitar portabilidade. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de processo 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de processo 
• Sistema convencional: 
•  Compilador gera código intermediário, parecido com código de 
máquina mas mais abstrato. 
•  Gerador de código utiliza código intermediário para gerar binário 
contendo código de máquina para ISA e SO específicos. 
•  Binário é distribuído e pode ser executado em plataformas que 
suportam tal combinação ISA/SO. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de processo 
• HLL VM: 
•  Compilador gera código de máquina abstrato em ISA virtual que 
especifica a interface da VM. 
•  Código virtual ISA, com informações de estruturas de dados 
associadas (metadados) é distribuído para execução em diferentes 
plataformas. 
•  Cada plataforma implementa uma VM capaz de carregar e executar o 
ISA virtual. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de processo 
• HLL VM: 
•  Java 
•  MS CLI 
•  Vantagem: fácil portar aplicação uma vez que a VM e bibliotecas 
estejam implementadas no hospedeiro. 
•  Implementação da VM demanda esforço, mas é mais simples que 
desenvolver compilador completo para cada plataforma e portar todas 
as aplicações através de recompilação. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de sistema 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de sistema 
•  Fornece ambiente completo onde mais um sistema 
operacional e seus muitos processos podem existir. 
• Utilização de VMM permite que única plataforma de 
hardware suporte múltiplos ambientes de sistema 
operacional simultaneamente. 
• Característica importante: isolamento entre sistemas 
concorrentes no mesmo hardware. 
•  Sem interferência em caso de falha. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de sistema 
• VMM fornece, primordialmente, replicação de plataforma. 
• Problema central: dividir recursos de hardware limitados 
entre múltiplos sistemas operacionais convidados. 
• VMM tem acesso e gerencia todos os recursos de hardware. 
• SO convidado e suas aplicações são gerenciadas sob 
controle (escondido) do VMM. 
• SO realiza instrução privilegiada ou acesso a recurso: VMM 
intercepta a operação, realiza verificações, e a realiza em 
nome do SO convidado. 
• SO convidado não é ciente dessa camada. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de sistema 
• Do ponto de vista do usuário, maioria dos sistemas de VM 
fornecem essencialmente a mesma funcionalidade mas 
diferem na forma de implementação. 
• Sistema de VMs clássico 
•  VMM diretamente sobre o hardware. 
•  VMM roda no modo de privilégio mais alto. 
•  Sistemas convidados rodam com privilégios reduzidos de forma a 
permitir a interceptação pela VMM. 
•  Ações de SO convidado que normalmente seriam interação direta com 
o hardware são tratadas pela VMM. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de sistema 
• Hosted VMs: 
•  Software de virtualização roda sobre um sistema operacional 
hospedeiro. 
•  Vantagem: usuário instala VMM como um software típico. 
•  Software de virtualização pode se apoiar no sistema operacional 
hospedeiro para utilizar drivers de dispositivos e outros serviços de 
nível mais baixo. 
•  VMWare GSX Server 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de sistema 
• Whole-system VMs: 
•  Hospedeiro e sistema convidado podem não utilizar mesmo ISA (Ex. 
Windows / Power-PC). 
•  Whole-system VMs virtualizam todoo software, incluindo SO e 
aplicações. 
•  ISA diferentes: necessário emular códigos das aplicações e do SO. 
•  Virtual PC. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de sistema 
• Multiprocessor virtualization 
•  Hospedeiro é máquina grande e multiprocessada. 
•  Particionar sistema em sistemas menores multiprocessados 
distribuindo os recursos de hardware 
•  Particionamento físico: recursos físicos separados para cada sistema 
virtualizado. 
•  Alto grau de isolamento. 
•  Particionamento lógico: hardware são multiplexados no tempo entre as 
diferentes partições. 
•  Melhorando utilização dos recursos. 
•  Perde-se alguns benefícios de isolamento de hardware. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de sistema 
• Codesigned VMs 
•  Implementam ISA novo e proprietário focado em melhoria de 
desempenho e eficiência energética. 
•  ISA do hospedeiro pode ser completamente novo ou extensão de ISA 
existente. 
•  Não possui aplicações nativas. 
•  VMM como parte da implementação de hardware com propósito único 
de emular ISA do software convidado. 
•  VMM reside em região de memória oculta dos softwares 
convencionais. 
•  Inclui tradutor binário que converte instruções do convidado em 
seqüências otimizadas de instruções do ISA do hospedeiro, usando um 
cache na região de memória oculta para reutilização. 
•  Transmeta Crusoe 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Máquinas virtuais de sistema 
•  Transmeta Crusoe 
•  Hardware: VLIW. 
•  Convidado: Intel IA-32 
•  Economia de energia. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Taxonomia 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Computação em nuvem 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Evolução 
•  Cluster Computing 
•  Um cluster (ou aglomerado) é um tipo de sistema de processamento 
paralelo ou distribuído, consistindo de uma coleção de computadores 
independentes interconectados e trabalhando cooperativamente como um 
único e integrado recurso computacional. 
•  Grid Computing 
•  Originalmente para colaborações científicas. 
•  Necessidade de compartilhamento de recursos coordenado e resolução de 
problemas em organizações virtuais dinâmicas e multi-institucionais. 
•  Computadores (PCs, estações de trabalho, clusters, supercomputadores, 
laptops, pdas, smartphones, ...) 
•  Agrega: 
•  Software (por exemplo, uso sob demanda de aplicações caras). 
•  Bancos de dados (por exemplo, acesso transparente a bancos de dados de 
genomas/proteínas). 
•  Instrumentos especiais (microscópios, lasers, telescópios,...). 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Evolução 
• P2P 
•  Não necessita de um servidor sempre ligado. 
•  Sistemas finais comunicam-se diretamente. 
•  Peers intermitentemente conectados e mudam de endereço. 
•  Paradigma que pode ser utilizado para conectar e gerenciar, por 
exemplo, uma grade computacional. 
•  Processos que constituem o sistema são todos iguais. 
•  Funções necessárias são executadas por todos. 
•  Interação simétrica: cliente e servidor ao mesmo tempo. 
•  Organização em rede de sobreposição. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Evolução 
• Utility Computing 
•  Computação como mercadoria / serviço. 
•  Pagamento e/ou troca. 
•  Associado a grades computacionais (utility grids). 
•  Diversos modelos de negócio / comercialização. 
• Cloud Computing 
•  Traz uma “combinação” de utility computing com virtualização. 
•  Avanço das redes e conexão à internet mais barata e mais rápida 
permitiu que se tornasse muito mais popular que as grades 
computacionais pagas. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Evolução 
• GridEcon (2007). 
• Grades tiveram sucesso em alguns pontos, mas não tanto 
quanto esperado. 
• Usada para consolidar recursos computacionais e 
economizar. 
•  Por exemplo, combinar poder computacional distribuído para otimizar 
cálculos e diminuir tempo de desenvolvimento de produtos. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Evolução 
•  Faltava acesso a poder computacional sob demanda, 
facilidade de acesso, modelo de pagamento pelo uso. 
• Poder computacional sob demanda: permite que empresas 
atendam demanda inesperada ou planejada de forma 
economicamente eficiente. 
• Simplicidade de acesso permite usuários utilizar recursos 
sem muito esforço ou conhecimento técnico. 
• Pagamento pelo uso permite minimização de investimento, 
permitindo empresas menores competirem com maiores. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Evolução 
• Necessário: 
•  Service oriented computing – encapsulamento e facilidade de uso. 
•  Virtualização – compartilhamento transparente e consolidação de 
servidores. 
•  Network computing – acesso uniforme à Internet. 
•  Faltavam: serviços “economicamente habilitados” 
•  Permitiriam avaliação de risco e 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Evolução 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Evolução 
• Provedor: fornece ferramentas para a comercialização de 
recursos. 
•  Ajuda a contornar problemas da grade, como risco na utilização de 
recursos externos, falta de confiança, risco de compromisso de 
compra, incerteza no planejamento de capacidade. 
•  Garantias contra perda financeira na indisponibilidade ou falha de 
recursos. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Evolução 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing 
• Acesso a computadores e suas funcionalidades via Internet 
ou rede local. 
• Requisição de serviço via conjunto de serviços que 
gerenciam um conjunto de recursos computacionais. 
• Usuário não precisa saber onde os recursos estão, ter 
conhecimento sobre a tecnologia, ou ter controle sobre a 
infra-estrutura de computação. 
•  Tipicamente envolve a provisão de recursos dinamicamente 
escaláveis e frequentemente virtualizados como serviço 
sobre a Internet. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing - características 
• Recursos sob-demanda, self-service. 
• Acesso ubíquo pela rede. 
•  Independente de localização. 
• Elasticidade rápida (escalabilidade). 
• Pagamento pelo uso. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – motivação 
•  1.8 zettabytes (10^21 bytes – giga, tera, peta, exa, zetta) de 
dados criados e replicados em 2011. 
• Se cada um fosse armazenar seus dados em dispositivos 
pessoais: 57.5 bilhões de iPads de 32 GB ~ $34.4 trilhões 
•  PIB dos EUA, Japão, China, Alemanha, França, Reino Unido e Itália 
somados. 
•  Compartilhamento dependeria fortemente de uma rede P2P. 
•  48 horas de vídeo enviados ao youtube por minuto. 
•  80.5 exabytes por mês de tráfego de dados na internet (~28 
milhões de DVDs por hora). 
• Relatório de usuários (AFCOM): economia de 21% ao mover 
aplicações para a nuvem. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – motivos para adoção 
•  61% Escalabilidade 
•  54% Economia 
•  53% Facilidade de gerência 
•  49% Redundância 
•  49% Maior flexibilidade 
•  48% Elasticidade 
•  34% Melhoria na utilização de hardware. 
•  32% Segurança 
•  6% Outros 
•  Cloud Computing Outlook 2011 
•  http://www.cloud.com/cloud-computing-outlook/survey.pdf 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing - implementação 
• Datacenters ocupam até 100 mil metros quadrados (17 
campos de futebol). 
•  5.75 milhões de novos servidores instalados por ano para 
atender aumento da demanda de serviços online. 
• Refrigeração consome até 30% da energia em um 
datacenter. 
•  1 datacenter ~ energia usada por 25.000 casas. 
•  IT: responsável por 2% das emissões globais de carbono. 
•  EUA: 14%, Datacenters, 37% Telecom, 50% dispositivos de usuário. 
•  Datacenters: 0.28% do total de energia consumida. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing - utilização 
•  74% das companhias utilizam alguma serviço de nuvem 
(março-abril 2011). 
•  84% dos gerentes deTI dizem que a empresa usa pelo 
menos uma aplicação de nuvem (maio 2011). 
•  79% dos diretores de TI citaram que executam alguma 
aplicação em produção na nuvem. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing - utilização 
•  64% dos diretores de TI antecipam que precisarão de novas 
ferramentas de gerência ao mover mais sistemas para a 
nuvem. 
• Estratégia de uso hoje: 
•  Nuvem privada: 24% 
•  Nuvem pública: 37% 
•  Nuvem híbrida: 39% 
• Estratégia de uso no futuro: 
•  19%, 24%, 57%. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – prós e contras 
•  http://www.mariaspinola.com/whitepapers/An_Essential_Guide_to_Possibilities_and_Risks_of_Cloud_Computing-
A_Pragmatic_Effective_and_Hype_Free_Approach_For_Strategic_Enterprise_Decision_Making.pdf 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing - atributos 
• Substrato / infra-estrutura são abstraídos e oferecidos como 
serviço. 
• Construída sobre infra-estrutura escalável e flexível. 
• Oferece provisão de serviço sob demanda e garantias (?) de 
qualidade de serviço. 
• Pagamento pelo uso de recursos computacionais sem a 
necessidade de compromisso prévio por parte dos usuários. 
• Compartilhada e multi-tenant (1 software – vários usuários). 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing 
• Coleção de computadores virtualizados interconectados e 
dinamicamente provisionados que se apresentam como um 
ou mais recursos unificados. 
• Usa-se qualquer dispositivo computacional para acessar a 
nuvem. 
• Em geral, acordos de nível de serviço (SLA – service level 
agreements) são utilizados para estabelecer os termos de 
serviço. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing 
•  “Cloud computing is a model for enabling convenient, on-
demand network access to a shared pool of configurable 
computing resources (e.g., networks, servers, storage, ap- 
plications, and services) that can be rapidly provisioned and 
released with minimal management effort or service provider 
interaction. This cloud model promotes availability.” (NIST) 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing 
• Diferente de outros termos, não é uma nova tecnologia. 
•  Novo modelo de operação conjunta de tecnologias existentes. 
•  Tecnologias existentes aplicadas à negócio. 
•  Virtualização. 
•  Grid computing. 
•  Utility computing. 
•  Preço baseado em utilidade. 
•  Computação autonômica / auto-gerência. 
•  Elasticidade. 
• Cloud computing alavanca tecnologias para promover o 
encontro de requisitos tecnológicos econômicos da atual 
demanda por tecnologia da informação. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Modelos de 
camadas 
•  Qi Zhang; Lu Cheng; Raouf Boutaba. Cloud computing: state of the art and research challenges, JISA, 2010. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Camadas 
• Camada de hardware 
•  Gerência dos recursos físicos da nuvem. 
•  Servidores, roteadores, switches, energia, refrigeração. 
•  Tipicamente implementada em um datacenter, com milhares de 
servidores organizados em racks e interconectados por roteadores e 
switches. 
•  Problemas: Configuração de hardware, tolerância a falhas, gerência de 
tráfego, energia, gerência de refrigeração. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Camadas 
• Camada de infra-estrutura (ou camada de virtualização) 
•  Cria um conjunto de recursos computacionais e de armazenamento 
através do particionamento dos recursos físicos utilizando tecnologias 
de virtualização (Xen, KVM, VMWare...). 
•  Características, como atribuição dinâmica de recursos, podem ser 
realizadas graças à virtualização. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Camadas 
• Camada de plataforma: 
•  Construída sobre a camada de infra-estrutura. 
•  Sistema operacional e frameworks de aplicação. 
•  Minimizar o ônus de disponibilizar aplicações diretamente sobre VMs. 
•  Google App Engine opera no nível de plataforma para prover APIs que 
suportam implementação de armazenamento / bancos de dados e 
lógica de aplicações web típicas. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Camadas 
• Camada de aplicação: 
•  Nível mais alto da hierarquia. 
•  Aplicações em nuvem. 
•  Mais modular que aplicações tradicionais, permitindo que camadas 
evoluam independentemente (similar ao modelo ISO/OSI em redes). 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Modelo de negócio 
• Software as a Service (SaaS) 
•  Aplicações online. 
•  Usuário não tem controle de desenvolvimento sobre aplicação ou 
ambiente de execução. 
•  Google Apps, Salesforce.com 
• Platforma as a Service (PaaS) 
•  Clientes utilizam ambiente de desenvolvimento e/ou hospedagem na 
nuvem para suas aplicações. 
•  Google App Engine, Amazon Web Services. 
•  Tipicamente um framework de desenvolvimento. 
•  Infrastructure as a Service (IaaS) 
•  Recursos computacionais (processamento, armazenamento, RAM), 
geralmente na forma de VMs. 
•  Usuário controla ambiente de desenvolvimento / aplicações. 
•  Amazon EC2, Globus Nimbus, Eucalyptus, OpenNebula, OpenStack. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Outros modelos 
•  Qi Zhang; Lu Cheng; Raouf Boutaba. Cloud computing: state of the art and research challenges, JISA, 2010. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing 
•  http://www.mariaspinola.com/whitepapers/An_Essential_Guide_to_Possibilities_and_Risks_of_Cloud_Computing-
A_Pragmatic_Effective_and_Hype_Free_Approach_For_Strategic_Enterprise_Decision_Making.pdf 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Outros modelos 
• HaaS – Hardware as a Service (licenciamento versus 
pagamento pelo uso). 
• PRaaS – Process as a Service. 
• DBaaS – Database as a Service. 
•  ... 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Modelos de 
implantação 
• Pública: provedores oferecem recursos computacionais 
pagos a qualquer usuário. 
• Privada: nuvem cujos recursos podem ser acessados e 
utilizados por indivíduos em uma organização. 
• Híbridas: combina recursos de nuvens públicas e híbridas, 
resultando em um controle sobre desempenho e segurança 
com elasticidade. 
• Comunitária: organizações compartilham nuvem. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Exemplos de uso 
• Animoto 
•  Cria vídeos para clientes/corporações. 
•  Usa Amazon EC2 e S3. 
•  Picos extremos de uso, indo de 70 a 8.500 servidores em 5 dias. 
• Harvard Medical School 
•  Laboratory for Personalized Medicine (LPM) utiliza AMI (imagem para 
máquinas da Amazon) personalizada. 
•  Modelos e montagem de genoma em tempo menor que seria possível 
sem a nuvem. 
• Washington Post 
•  Usou Amazon EC2 para transformar 17.481 páginas PDF “não-
buscáveis” em páginas buscáveis em 24 horas (agenda de Hillary 
Clinton). 
•  Levaria 30 minutos por página em softwares de OCR locais. 
•  Usou 1427 horas de VM por 144.62 dólares. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Exemplos de uso 
• Webiste Virgin Atlantic (vtravelled.com). 
• NASA/JPL: streaming de imagens e vídeo do pouso da 
sonda Curiosity em marte. 
• NASDAQ Maket Replay: S3 para armazenar dados 
históricos do mercado. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – alguns pontos 
• Planejamento de capacidade e gerência de SLA. 
• Desconhecido do usuário: 
•  Localização dos dados – cumpre com requisitos regulatórios? 
•  Perda de dados – qual procedimento de backup/restauração? 
•  Segurança de dados – procedimentos seguidos para proteger os 
dados? 
•  Limpeza dos dados depois da descontinuidade do serviço. 
•  Falta de padronização: 
•  IaaS – templates de máquinas virtuais. 
•  IaaS – upload, download, inspeção, configuração,ações (criar nova 
máquina, destruir máquina, etc). 
•  IaaS / PaaS – portabilidade de dados e código. 
•  PaaS – escolha de um framework oferecido por múltiplos provedores e 
evitar extensões específicas (cloud lock-in). 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Cobrança 
• Exemplos de modelos de cobrança: 
•  IaaS: tempo de uso da máquina virtual, armazenamento adicional. 
•  PaaS: número de requisições. 
•  *aaS: transferências de dados. 
•  IaaS (EC2): 
•  Sob demanda 
•  Reservada 
•  Spot 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Cobrança 
• Exemplos de preços: 
•  IaaS: 
•  U$1.64/2.04 (linux/win) por hora (68.4 GB RAM, 26 EC2 Compute Units (8 
virtual cores com 3.25 EC2 Compute Units cada), 1690 GB de 
armazenamento na instância, 64-bits, desempenho de I/O alto, EBS-
Optimized: 1000 Mbps. 
•  U$2.40/2.97 por hora. Cluster Compute Eight Extra Large Instance: 60.5 GB 
RAM, 88 EC2 Compute Units (2 x Intel Xeon E5-2670, eight-core), 3370 GB 
of instance storage, 64-bits, I/O Performance: muito alta (10 Gigabit 
Ethernet). 
•  Armazenamento: Amazon EBS Standard volumes $0.10 por GB-mês,$0.10 
por 1 milhão de requisições de I/O. 
•  Transferência de dados (da nuvem para internet): 1 GB grátis, até 10TB: 
0.12/GB(...) 
•  Também depende de localidade. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Padronização 
• Padronização pode trazer benefícios para usuários: 
•  Competição / preços 
•  Interoperabilidade 
•  Transparência técnica para personalização 
• Provedores 
•  Não tem incentivo para padronizar 
•  Benefícios de produtos proprietários versus potenciais 
consumidores com tecnologias padronizadas 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Padronização 
•  Cloud Computing Interoperability Forum 
•  Início em 2008, parada em 2010, retomada em 2012 
•  NIST US Government Cloud Computing Technology Roadmap 
– 2011 
•  ITU Telecommunication Standardization Bureau 
•  Activities in Cloud Computing Standardization – 2010 
•  OCC, IETF, OASIS... 
•  EC2 
•  VMs Xen, podem ser criadas com ferramentas livres 
•  Interfaces HTTP 
•  OpenStack 
•  Software de código aberto para implantação de nuvens privadas e 
públicas 
•  150+ companhias, 9000+ pessoas 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Padronização 
Cloud Computing – An enterprise perspective. Raghavan Subramanian Infosys Technologies Limited 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Padronização 
Cloud Computing – An enterprise perspective. Raghavan Subramanian Infosys Technologies Limited 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Padronização 
Cloud Computing – An enterprise perspective. Raghavan Subramanian Infosys Technologies Limited 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Padronização 
•  Falta de padronização 
•  Templates de máquinas virtuais (Open Virtualization Format) 
•  IaaS – upload, download, inspeção, configuração, criação de 
instâncias 
•  IaaS/PaaS – portabilidade de código e dados. 
•  PaaS – escolha de um arcabouço oferecido por múltiplos 
provedores e que evite extensões específicas de provedor. 
•  Jclouds 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Lock-in 
• Obstáculo para adoção de cloud computing. 
• Aprisionamento a um determinado provedor devido à falta 
de padrões e/ou produtos compatíveis. 
• Arriscado 
•  Aumento de preços 
•  Provedor pode tornar-se obsoleto, fechar, tornar-se não-
confiável... 
• Padronização por si só também não resolve 
•  Interface padrão não garante desempenho ou escalabilidade. 
• Provedores podem oferecer ferramentas extras, além de 
implementação baseada em software aberto. 
• Data lock-in – custo de recriar / transferir dados 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack 
• OpenStack is a cloud operating system that controls large 
pools of compute, storage, and networking resources 
throughout a datacenter, all managed through a dashboard 
that gives administrators control while empowering their 
users to provision resources through a web interface. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack 
• Dashboard, Compute, Networking, Storage 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack Dashboard 
•  Interface gráfica para administração e usuários. 
• Personalizável para provedores de serviço 
• Desenvolvedores podem utilizar outros recursos (APIs) para 
automatizar tarefas sem uso do dashboard. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack Dashboard 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack Dashboard 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack Dashboard 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack Dashboard 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack Dashboard 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack Dashboard 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack Dashboard 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack Dashboard 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack Dashboard 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack Compute 
•  “OpenStack Compute: Provision and manage large networks 
of virtual machines” 
• Arquitetura flexível: permite implantação diretamente sobre o 
hardware ou sobre uma camada de virtualização. 
•  Frequentemente implementado usando KVM ou Xen. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack Networking 
•  “OpenStack Networking: Pluggable, scalable, API-driven 
network and IP management.” 
• Permite uso de VLAN ou redes flat 
• Gerencia IPs, permitindo re-roteamento de tráfego durante 
manutenção ou falha. 
• Usuários podem criar suas próprias redes, controlar tráfego, 
e conectar servidores e dispositivos a uma ou mais redes. 
• Suporte a utilização de software defined networks 
• Possui extensão que permite serviços adicionais (detecção 
de intrusão, balanceamento de carga, firewalls, VPNs). 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack Storage 
•  “OpenStack Storage: Object and Block storage for use with 
servers and applications.” 
• Object storage: plataforma acessível por APIs que pode ser 
integrada diretamente às aplicações ou usada para backup. 
• Block storage: permite uso de dispositivos de disco através 
das instâncias. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack Object Storage 
• Sistema de armazenamento distribuído para dados estáticos 
(imagens de VMs, fotos, emails, backups..). 
• Objetos e arquivos são escritos em múltiplos discos 
espalhados pelos servidores no datacenter. 
•  OpenStack é responsável por replicação e integridade. 
• Escalabilidade horizontal através da adição de mais 
servidores. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
OpenStack Block Storage 
• Armazenamento persistente para instâncias de computação. 
• Gerencia criação, acoplamento e desacoplamento dos 
dispositivos de bloco aos servidores. 
•  Permite ao usuário gerenciar suas necessidades. 
• Apropriado para cenários sensíveis a desempenho. 
• Snapshot permite backups que podem ser restaurados ou 
reutilizados para criar novos volumes. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing e Datacenters 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Datacenter 
• Abordagem em camadas: core, aggregation, access. 
•  Qi Zhang; Lu Cheng; Raouf Boutaba. Cloud computing: state of the art and research challenges, JISA, 2010. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Datacenter 
• Access 
•  Conexão dos racks com a rede. 
•  Tipicamente 20 a 40 servidores por rack, cada um conectado a um 
switch de acesso com um enlace de 1Gbps. 
•  Switches dessa camada conectam-se geralmente a dois switches 
(para redundância)com enlaces de 10Gbps. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Datacenter 
• Aggregation: 
•  Balanceamento de carga 
•  Serviços de domínio 
•  Serviços de localização 
•  SSL offloading 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Datacenter 
• Core: 
•  Conectividade entre múltiplos switches de agregação. 
•  Gerencia tráfego que entra e sai do datacenter. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Datacenter 
• Comum utilizar switches e roteadores “populares” para 
implementação da infra-estrutura de rede. 
• Objetivos: 
•  Alta capacidade uniforme: taxa máxima de servidor para servidor deve 
ser limitada somente pela capacidade disponível na interface dos 
servidores. Qualquer host deve ser capaz de se comunicar com 
qualquer host a essa capacidade máxima. 
•  Migração de VMs livre: deve ser capaz de realizar migração de 
máquinas virtuais para multiplexação estatística ou mudança dinâmica 
de padrões para alcançar largura de banda alta para hosts fortemente 
acoplados, ou para alcançar distribuição de calor apropriada. Topologia 
deve suportar migração rápida de VMs. 
•  Resiliência: falhas são comuns quando se escala. Rede deve ser 
tolerante a falhas, sobrecarga de enlaces, falha de servidores e racks. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Datacenter 
• Objetivos: 
•  Escalabilidade: infra-estrutura de rede deve ser capaz de suportar um 
grande número de servidores e permitir expansão incremental. 
• Área de inovação na indústria: 
•  Projeto e desenvolvimento de modular data center (MDC) em 
containers. 
•  Alguns milhares de servidores conectados por switches. 
•  Aplicações altamente interativas sensíveis a tempo de resposta. 
•  Redundância. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Datacenter 
• MDC – BCube. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Datacenter 
•  Velocidade de instalação 
•  Baixo custo de implantação e operação 
•  Alta mobilidade 
•  Melhor eficiência energética 
Fabrizio Granelli - DESIGN OF GREEN NETWORKS: TOWARDS THE GREEN 
INTERNET 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Datacenter 
• Até 46.080 cores 
•  30 petabytes de armazenamento 
• Baixo custo de refrigeração e energia. 
Fabrizio Granelli - DESIGN OF GREEN NETWORKS: TOWARDS THE GREEN 
INTERNET 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Energia 
• DESIGN OF GREEN NETWORKS: TOWARDS THE GREEN 
INTERNET 
Fabrizio Granelli - DESIGN OF GREEN NETWORKS: TOWARDS THE GREEN 
INTERNET 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Energia 
Fabrizio Granelli - DESIGN OF GREEN NETWORKS: TOWARDS THE GREEN 
INTERNET 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Computação em Nuvem: alguns desafios 
Desafios da Computação em Nuvem - 139 
•  Modelos de preços 
•  Provisionamento autônomo de serviços 
•  Migração de máquinas virtuais 
•  Consolidação de servidores 
•  Gerência de energia (Green Computing) 
•  Análise e gerência de tráfego 
•  Mecanismos de segurança de informações 
•  Frameworks de software 
•  Tecnologias para armazenamento e gerência de informações 
•  Localização e instanciação automática de máquinas virtuais 
•  Gerência de execução de workflows em IaaSs concorrentes 
•  Novas arquiteturas para a Nuvem 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Green Computing 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Energia 
Fabrizio Granelli - DESIGN OF GREEN NETWORKS: TOWARDS THE GREEN 
INTERNET 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Energia 
Fabrizio Granelli - DESIGN OF GREEN NETWORKS: TOWARDS THE GREEN 
INTERNET 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing – Energia 
Fabrizio Granelli - DESIGN OF GREEN NETWORKS: TOWARDS THE GREEN 
INTERNET 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Fabrizio Granelli - DESIGN OF GREEN NETWORKS: TOWARDS THE GREEN 
INTERNET 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Fabrizio Granelli - DESIGN OF GREEN NETWORKS: TOWARDS THE GREEN 
INTERNET 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Fabrizio Granelli - DESIGN OF GREEN NETWORKS: TOWARDS THE GREEN 
INTERNET 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Fabrizio Granelli - DESIGN OF GREEN NETWORKS: TOWARDS THE GREEN 
INTERNET 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Fabrizio Granelli - DESIGN OF GREEN NETWORKS: TOWARDS THE GREEN 
INTERNET 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Fabrizio Granelli - DESIGN OF GREEN NETWORKS: TOWARDS THE GREEN 
INTERNET 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Fabrizio Granelli - DESIGN OF GREEN NETWORKS: TOWARDS THE GREEN 
INTERNET 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Fabrizio Granelli - DESIGN OF GREEN NETWORKS: TOWARDS THE GREEN 
INTERNET 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Fabrizio Granelli - DESIGN OF GREEN NETWORKS: TOWARDS THE GREEN 
INTERNET 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Cloud Computing - Datacenters 
•  Economia de energia através da melhoria da 
eficiência da rede. 
•  Economia de energia através da melhor utilização 
dos servidores. 
•  Alocação de máquinas virtuais. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Escalonamento em Nuvem: provedor IaaS 
• Usuários requisitam máquinas virtuais de acordo 
com capacidades oferecidas pelos IaaSs. 
• Provedor de IaaS possui demanda variável: baixa 
demanda deixa recursos ociosos e alta demanda 
pode refletir no QoS ao usuário. 
• Como alocar as máquinas virtuais dentro do 
datacenter de modo a atender o QoS e minimizar 
custos de manutenção e energia? 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Escalonamento em Nuvem: provedor IaaS 
q Concentrar máquinas virtuais em poucas 
máquinas físicas: possibilita desligar 
máquinas sub-utilizadas. 
q Ao selecionar recurso físico para alocar 
VM, levar em conta: carga atual do 
recurso, consumo de energia 
considerando DVFS (Dynamic Voltage 
and Frequency Scaling), e consumo de 
energia considerando Fan Control. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
•  Estimation of Power Consumption in Cloud 
Computing (Metric: Billions of kWh) 
GREENPEACE. “Make IT Green – Cloud Computing and its Contribution to Climate Change”. 
Data Centers Telecom Total
0
200
400
600
800
1000
1200
1400
1600
1800
2000
2007
2020
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
•  MtCO2e emissions (2007 emissions and projected 
emissions for 2020) 
 MtCO2e = Metric Tonne Carbon Dioxide Equivalent 
GREENPEACE. “Make IT Green – Cloud Computing and its Contribution to Climate Change”. 
World Datacenters Telecom PC's
0
200
400
600
800
1000
1200
1400
1600
2007
2020
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
•  Improves manageability, performance, and fault tolerance 
of systems. 
•  Balances system load. 
•  Migrating VMs out of overloaded/overheated servers 
•  Need of bringing servers down for maintenance after 
migrating their workload to other servers 
•  In this work: 
•  Virtual machine migration are used in order to migrate 
the virtual loads of underutilized hosts and then turn 
them off, thereby maximizing energy savings. 
Migração de máquinas virtuais 
•  LAGO, D. G. ; MADEIRA, E. R. M. ; BITTENCOURT, L. F. . Power-Aware Virtual Machine Scheduling on 
Clouds Using Active Cooling Control and DVFS. In: 9th International Workshop on Middleware for Grids, 
Clouds and e-Science, 2011, Lisboa. ACM/IFIP/USENIX 12th International Middleware Conference, 2011. 15. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
DVFS 
•  Intel Speed Step technology or AMD Coll'n'Quiet 
automatically adjusts, in hardware, the operating 
voltage and frequency of their processors according 
to their workloads 
•  High loads: the processor raises the levels of 
voltage and frequency 
•  Low loads: These levels decrease•  In this work: 
•  DVFS is always applied, with the goal of having 
the intelligent use of the processor power, 
adapted to the loads that it needs to process 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Fan Control 
• Monitors the temperature of the computers and, through 
thermal conditions, regulates the intensity of active 
coolers according to the processor heating 
• Several Names: AOpen: SilentTEK; ASUS: Q-Fan; MSI: 
Core Center; Abit: μGuru; Gigabyte: EasyTune 6; Intel 
S478: Active Monitor / Desktop Control Center; Intel 
S775: Desktop Utilities and Dell Inspiron/Latitude/
Precision: I8kfanGUI 
• Direct consequence: Reduces energy consumption 
• In this work: 
• We use this mechanism with DVFS to optimize 
energy consumption 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Algoritmo 
•  Scope: 
•  Non-federated datacenters (all hosts are in the 
same cloud) 
•  DVFS and Fan Control enabled for all hosts 
•  Datacenter with homogeneous or heterogeneous 
machine configurations 
•  Workload weight known or not – dynamically 
checks the processing needs and optimizes energy 
consumption on-the-fly 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Algoritmo 
•  Some Broker functions: 
•  Resource requests 
•  Virtual machine creation 
•  Workload return 
•  Finalization of workloads and virtual machines 
We work here! 
“Host Allocation for virtual machines” 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
1. For each VM to be allocated in the datacenter, check 
the hosts that can receive that VM 
VM 
1000 MIPS 
RAM, BW, etc... 
Server A1 
750 Free MIPS 
RAM, BW, etc... 
Server A2 
1500 Free MIPS 
RAM, BW, etc... 
not candidate 
candidate 
Algoritmo 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
For candidate hosts... 
2. Checks and selects the host with best energy 
efficiency 
Server Cand. B1 
1000 Total MIPS 
150 Watts 
EE = 6,67 
Server Cand. B2 
1500 Total MIPS 
200 Watts 
EE = 7,5 
Server Cand. B3 
2000 Total MIPS 
350 Watts 
EE = 5,7 
Algoritmo 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Tie case (1)… 
3.  Calculates the power of each host after VM 
allocation and selects the lesser energy consumer 
Server Cand. C1 
125 watts after 
allocation 
Server Cand. C2 
129 watts after 
allocation 
Server Cand. C3 
128 watts after 
allocation 
Algoritmo 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Tie case (2)... 
3.  The host with the highest CPU utilization is selected 
to reduce migrations 
Server Cand. D1 
80% CPU usage 
Server Cand. D2 
35% CPU usage 
Server Cand. D3 
85% CPU usage 
Algoritmo 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
In tie case (last)... 
3.  The server with highest MIPS is chosen 
Server Cand. E1 
2000 MIPS 
Server Cand. E2 
2500 MIPS 
Server Cand. E3 
1500 MIPS 
Algoritmo 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
•  Simulator used: CloudSim 2.2.1 (The CLOUDS Lab; 
University of Melbourne; Buyya, R.; Ranjan, R.; 
Calheiros, R.; Beloglazov, A.) 
•  EC = Energy Consumption 
•  ECI = 95% Energy Consumption Confidence Interval 
•  TC = Time Consumption 
•  TCI = 95% Time Consumption Confidence Interval 
•  A = Algorithm (i.e.: MPD, LA) 
•  C = Configurations (i.e.: Threshold, DVFS) 
•  P = Set of Parameters (i.e.: number of hosts, 
number of VMs, MI per cloudlet) 
•  30 Simulations for each scenario 
Simulações 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Simulações 
•  Small 
•  10 hosts, 20 VMs, 20 cloudlets 
•  Medium 
•  100 hosts, 200 VMs, 200 cloudlets 
•  Large 
•  1000 hosts, 2000 VMs, 2000 cloudlets 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Simulações 
•  Each host on both homogeneous and heterogeneous 
datacenter has 
•  1 Processing Entity (processor) 
•  Disk Space: 1 TB 
•  RAM: 24 GB 
•  Ethernet: Gigabit 
•  Architecture: x86 
•  VM Monitor: Xen 
•  OS: Linux 
•  Cloudlet File Size: 300 bytes, before and after 
processing 
•  Cloudlet Millions of Instructions: {100 k; 150 k; 
200 k; 250 k} MI, round-robin distribution 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Simulações 
•  Each VM on both homogeneous and heterogeneous 
datacenter has 
•  VM MIPS: {500, 750, 1000} MIPS, round-robin 
distribution 
•  VM RAM: 128 MB 
•  VM Bandwidth: 2500 Kbps 
•  VM Image Size: 2.5 MB 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Simulações 
VM ID VM1 VM2 VM3 VM4 VM5 
MIPS 500 750 1000 500 750 
Clet. ID C1 C2 C3 C4 C5 
Clet. MI 100 k 150 k 200 k 250 k 100 k 
Cloudlet Allocation on VMs 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Simulações 
•  Each host on both homogeneous and heterogeneous 
datacenter has 
•  DVFS Enabled, linear power model 
Processing Level 100% 
 
 
50% 
 
 
0% 
250 Watts Power Consumption 
 
 
212 Watts 
 
 
175 Watts 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Simulações 
•  Each host on both homogeneous and heterogeneous 
datacenter has 
•  Fan Control Enabled, linear power model. Based 
on i5 750 stock cooler. Min Voltage: 5 V; 
Maximum Voltage: 12 V. 
Processing Level 100% 
 
 
50% 
 
 
0% 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Simulações 
•  Each host on homogeneous datacenter has 
•  Processor: 2000 MIPS 
•  Power Consumption: 250 watts 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Simulações 
•  Each host on heterogeneous datacenter has 
•  Processor: 1000, 1500, 2000, 2500, 3000 MIPS; 
round-robin distribution 
•  Power Consumption: 200, 250, 300 and 350 
watts; round-robin distribution 
Host H1 H2 H3 H4 H5 H6 
MIPS 1000 1500 2000 2500 3000 1000 
Power 200 250 300 350 200 250 
I.e.: Host 5 will have 3000 
MIPS and consumes 200 watts 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Simulações 
•  Analyzed Algorithms 
•  RR = Round Robin 
•  BRS = Best Resource Selection 
•  MPD = Minimum Power Diff 
•  LA = Lago Allocator 
•  Settings for Each Simulation 
•  N = Non Power Aware 
•  P = Power Aware (shutdown of unused hosts) 
•  D = DVFS 
•  T = Threshold 
•  F = Fan Control 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Simulações 
•  Small Homogeneous Data Center 
•  Analyzed Algorithms 
•  RR = Round Robin 
•  BRS = Best Resource Selection 
•  MPD = Minimum Power Diff 
•  LA = Lago Allocator 
•  Settings for Each Simulation 
•  N = Non Power Aware 
•  P = Power Aware (shutdown of unused hosts) 
•  D = DVFS 
•  T = Threshold 
•  F = Fan Control 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Simulações 
•  Small Heterogeneous Data Center 
•  Analyzed Algorithms 
•  RR = Round Robin 
•  BRS = Best Resource Selection 
•  MPD = Minimum Power Diff 
•  LA = Lago Allocator 
•  Settings for Each Simulation 
•  N = Non Power Aware 
•  P = Power Aware (shutdown of unused hosts) 
•  D = DVFS 
•  T = Threshold 
•  F = Fan Control 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Simulações 
•  Medium Homogeneous Data Center 
•  Analyzed Algorithms 
•  RR = Round Robin 
•  BRS = Best Resource Selection 
•  MPD = Minimum Power Diff 
•  LA = Lago Allocator 
•  Settings for Each Simulation 
•  N = Non Power Aware 
•  P = Power Aware (shutdown of unused hosts) 
•  D = DVFS 
•  T = Threshold 
•  F = Fan Control 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Simulações 
•  Medium Heterogeneous Data Center 
•  Analyzed Algorithms 
•  RR = Round Robin 
•  BRS = Best Resource Selection 
•  MPD = Minimum Power Diff 
•  LA = Lago Allocator 
•  Settings for Each Simulation 
•  N = Non Power Aware 
•  P = Power Aware (shutdown of unused hosts) 
•  D = DVFS 
•  T = Threshold 
•  F = Fan Control 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Simulações 
•  Large Homogeneous Data Center 
•  Analyzed Algorithms 
•  RR = Round Robin 
•  BRS = Best Resource Selection 
•  MPD = Minimum Power Diff 
•  LA = Lago Allocator 
•  Settings for Each Simulation 
•  N = Non Power Aware 
•  P = Power Aware (shutdown of unused hosts) 
•  D = DVFS 
•  T = Threshold 
•  F = Fan Control 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Simulações 
•  Large Heterogeneous Data Center 
•  AnalyzedAlgorithms 
•  RR = Round Robin 
•  BRS = Best Resource Selection 
•  MPD = Minimum Power Diff 
•  LA = Lago Allocator 
•  Settings for Each Simulation 
•  N = Non Power Aware 
•  P = Power Aware (shutdown of unused hosts) 
•  D = DVFS 
•  T = Threshold 
•  F = Fan Control 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Simulações 
•  Competitive Comparison 
Scenario MPD PDT-ECI 
MPD PDT+ECI LA PDTF-ECI LA PDTF+ECI Conclusion 
Small Homo 0.227 0.221 
Tie 
0.234 0.229 
Small Hetero 0.209 0.201 LA is better 
(0.5% to 7%) 0.215 0.208 
Medium Homo 2.204 2.163 LA is better 
(1% to 3.1%) 2.229 2.183 
Medium Hetero 2.091 2.007 LA is better 
(2.8% to 5.3%) 2.114 2.034 
Large Homo 21.982 21.674 LA is better from 
(1.1% to 1.8%) 22.061 21.751 
Large Hetero 20.890 19.770 LA is better 
(5.3% to 6.1%) 20.974 19.834 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Simulações 
•  Competitive Comparison 
Scenario MPD PDTF-ECI 
MPD PDTF+ECI LA PDTF-ECI LA PDTF+ECI Conclusion 
Small Homo 0.225 0.221 
Tie 
0.234 0.229 
Small Hetero 0.204 0.201 
Tie 
0.211 0.208 
Medium Homo 2.172 2.163 
Tie 
2.192 2.183 
Medium Hetero 2.035 2.007 LA is better 
(0.05% to 
3%) 2.066 2.034 
Large Homo 21.649 21.674 
Tie 
21.720 21.751 
Large Hetero 20.449 19.770 LA is better 
(3.1% to 4%) 20.558 19.834 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Conclusão 
•  LA PDTF remained between 15% (in the simulations 
with heterogeneous small datacenters) and 43% (in 
the simulations with homogeneous large 
datacenters) slower than the best algorithm in each 
of these simulations, 
•  Algorithm recommendation use 
•  Non-federated Datacenters only 
•  Homogeneous Datacenters – Fair results 
•  Heterogeneous Datacenters – Good results 
•  Cloudlets size known or not 
•  Active Cooling Control 
•  Generates small but relevant improvement 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Prioridades e QoS 
•  Outro problema: manter QoS com VMs prioritárias. 
•  Novo algoritmo 
•  Executado simultaneamente com o anterior 
•  Atua na submissão de cargas de trabalho 
•  Objetivo: minimização do consumo de energia e 
da poluição potencial gerada, garantindo 
qualidade de serviço. 
•  Métrica de QoS Abordada: Redução do tempo de 
execução de cargas de trabalho com alta 
prioridade, sem comprometer significativamente 
o consumo de energia 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Prioridades e QoS 
•  Problema Abordado 
Dado um conjunto composto por M máquinas 
virtuais e C cargas de trabalho, tendo cada carga Ci 
uma prioridade Pi associada, efetuar o 
escalonamento de C em M minimizando os tempos 
de execução das cargas com maior prioridade Pi, 
mantendo o consumo de energia. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Prioridades e QoS 
VM1 
VM2 
1500 MIPS 
RAM, BW, etc... 
VM2 
VM3 
1000 MIPS 
RAM, BW, etc... 
VM3 
VMs já foram instanciadas... 
VM4 
2500 MIPS 
RAM, BW, etc... 
VM4 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Prioridades e QoS 
Chegam as cloudlets... 
C1 
C2 
C3 
C4 
Cloudlet C1, 100 k MI 
Prioridade Alta 
RAM, BW, etc... 
Cloudlet C2, 100 k MI 
Prioridade Média 
RAM, BW, etc... 
Cloudlet C3, 200 k MI 
Prioridade Alta 
RAM, BW, etc... 
Cloudlet C4, 100 k MI 
Prioridade Baixa 
RAM, BW, etc... 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Prioridades e QoS 
Processa as cloudlets com maior prioridade... 
C1 
C2 
C3 
C4 
Cloudlet C1, 100 k MI 
Prioridade Alta 
RAM, BW, etc... 
Cloudlet C2, 100 k MI 
Prioridade Média 
RAM, BW, etc... 
Cloudlet C3, 200 k MI 
Prioridade Alta 
RAM, BW, etc... 
Cloudlet C4, 100 k MI 
Prioridade Baixa 
RAM, BW, etc... 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Prioridades e QoS 
VM1 
750 MIPS 
RAM, BW, etc... 
VM1 
VM2 
1500 MIPS 
RAM, BW, etc... 
VM2 
VM3 
1000 MIPS 
RAM, BW, etc... 
VM3 
Aloca as cloudlets... 
VM4 
2500 MIPS 
RAM, BW, etc... 
VM4 
C1 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Prioridades e QoS 
VM1 
750 MIPS 
RAM, BW, etc... 
VM1 
VM2 
1500 MIPS 
RAM, BW, etc... 
VM2 
VM3 
1000 MIPS 
RAM, BW, etc... 
VM3 
Aloca as cloudlets... 
VM4 
2500 MIPS 
RAM, BW, etc... 
VM4 
C1 
C3 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Prioridades e QoS 
Reduz a prioridade processada e verifica as cloudlets... 
C1 
C2 
C3 
C4 
Cloudlet C1, 100 k MI 
Prioridade Alta 
RAM, BW, etc... 
Cloudlet C2, 100 k MI 
Prioridade Média 
RAM, BW, etc... 
Cloudlet C3, 200 k MI 
Prioridade Alta 
RAM, BW, etc... 
Cloudlet C4, 100 k MI 
Prioridade Baixa 
RAM, BW, etc... 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Prioridades e QoS 
VM1 
750 MIPS 
RAM, BW, etc... 
VM1 
VM2 
1500 MIPS 
RAM, BW, etc... 
VM2 
VM3 
1000 MIPS 
RAM, BW, etc... 
VM3 
Aloca as cloudlets... 
VM4 
2500 MIPS 
RAM, BW, etc... 
VM4 
C1 
C3 
C2 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Prioridades e QoS 
Reduz a prioridade processada e verifica as cloudlets... 
C1 
C2 
C3 
C4 
Cloudlet C1, 100 k MI 
Prioridade Alta 
RAM, BW, etc... 
Cloudlet C2, 100 k MI 
Prioridade Média 
RAM, BW, etc... 
Cloudlet C3, 200 k MI 
Prioridade Alta 
RAM, BW, etc... 
Cloudlet C4, 100 k MI 
Prioridade Baixa 
RAM, BW, etc... 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Prioridades e QoS 
VM1 
750 MIPS 
RAM, BW, etc... 
VM1 
VM2 
1500 MIPS 
RAM, BW, etc... 
VM2 
VM3 
1000 MIPS 
RAM, BW, etc... 
VM3 
Aloca as cloudlets... 
VM4 
2500 MIPS 
RAM, BW, etc... 
VM4 
C1 
C3 
C2 
C4 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Prioridades e QoS 
•  Consumo de Energia em Data Centers Pequenos 
•  Analyzed Algorithms 
•  RR = Round Robin 
•  BRS = Best Resource Selection 
•  MPD = Minimum Power Diff 
•  LA = Lago Allocator 
•  Settings for Each Simulation 
•  N = Non Power Aware 
•  P = Power Aware (shutdown of unused hosts) 
•  D = DVFS 
•  T = Threshold 
•  F = Fan Control 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Prioridades e QoS 
•  Consumo de Energia em Data Centers Médios 
•  Analyzed Algorithms 
•  RR = Round Robin 
•  BRS = Best Resource Selection 
•  MPD = Minimum Power Diff 
•  LA = Lago Allocator 
•  Settings for Each Simulation 
•  N = Non Power Aware 
•  P = Power Aware (shutdown of unused hosts) 
•  D = DVFS 
•  T = Threshold 
•  F = Fan Control 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Prioridades e QoS 
•  Consumo de Energia em Data Centers Grandes 
•  Analyzed Algorithms 
•  RR = Round Robin 
•  BRS = Best Resource Selection 
•  MPD = Minimum Power Diff 
•  LA = Lago Allocator 
•  Settings for Each Simulation 
•  N = Non Power Aware 
•  P = Power Aware (shutdown of unused hosts) 
•  D = DVFS 
•  T = Threshold 
•  F = Fan Control 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Prioridades e QoS 
•  Makespan 
•  Analyzed Algorithms 
•  RR = Round Robin 
•  BRS = Best Resource Selection 
•  MPD = Minimum Power Diff 
•  LA = Lago Allocator 
•  Settings for Each Simulation 
•  N = Non Power Aware 
•  P = Power Aware (shutdown of unused hosts) 
•  D = DVFS 
•  T = Threshold 
•  F = Fan Control 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
•  Consumo de Energia 
���
	
P. Homo	

 P. Hetero	

 M. Homo	

 M. Hetero	

 G. Homo	

 G. Hetero	
LA PDTF x 
MPD PDT	

 Empate	
LA PDTF 
(de 15,5% a 
25,9%)	
LA PDTF 
(de 0,4% a 
2,7%)	
LA PDTF 
(de 7,0% a 
9,9%)	
LA PDTF 
(de 1,1% a 
1,9%)	
LA PDTF 
(de 7,3% a 
8,1%)	
LA PDTF x 
MPD 
PDTF	
Empate	
LA PDTF 
(de 12,5% a 
23,1%)	
Empate	
LA PDTF 
(de 6,6% a 
9,2%)	
Empate	
LA PDTF 
(de 5,4% a 
6,3%)	
LAQ 
PDTF x 
MPD PDT	
Empate	
LAQ PDTF 
(de 16,5% a 
26,8%)	
LAQ PDTF 
(de 0,8% a 
3,0%)	
LAQ PDTF 
(de 6,9% a 
9,9%)	
LAQ PDTF 
(de 0,8% a 
1,5%)	
LAQ PDTF 
(de 7,1% a 
7,9%)	
LAQ 
PDTF x 
MPD 
PDTF	
Empate	
LAQ PDTF 
(de 13,5% a 
24%)	
Empate	
LAQ PDTF 
(de 6,5% a 
9,3%)	
Empate	
LAQ PDTF 
(de 5,3% a 
6,1%)	
LA PDTF x 
LAQ 
PDTF	
Empate	

 Empate	

 Empate	

 Empate	
LA PDTF 
(de 0% a 
0,8%)	
EmpatePrioridades e QoS 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
•  Tempo de Execução de Cloudlets 
Cenário	

 Priorid. Carga	

 LA PDTF (1)	

 LAQ PDTF (2)	

 Melhor	
Pequeno Homo	

 Baixa	

 677,97±5,98	

 892,10±7,62	

 (1), de 22,67% a 
25,31%	
Normal	

 641,38±4,52	

 650,65±4,40	

 (1), de 0,05% a 
2,78%	
Alta	

 649,53±6,27	

 451,23±4,07	

 (2), de 29,22% a 
31,81%	
Pequeno 
Hetero	
Baixa	

 667,77±5,58	

 870,17±6,11	

 (1), de 22,07% a 
24,43%	
Normal	

 632,22±4,68	

 636,85±3,87	

 Empate	
Alta	

 639,10±4,89	

 440,03±4,66	

 (2), de 29,88% a 
32,39%	
Prioridades e QoS 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
•  Tempo de Execução de Cloudlets 
Cenário	

 Priorid. Carga	

 LA PDTF (1)	

 LAQ PDTF (2)	

 Melhor	
Médio Homo	

 Baixa	

 671,81±5,42	

 923,34±6,04	

 (1), de 26,17% a 
28,30%	
Normal	

 664,35±4,35	

 641,70±3,08	

 (2), de 2,31% a 
4,50%	
Alta	

 666,62±6,26	

 456,06±3,61	

 (2), de 30,39% a 
32,76%	
Médio Hetero	

 Baixa	

 664,66±3,82	

 924,66±6,10	

 (1), de 27,22% a 
29,00%	
Normal	

 664,53±3,36	

 643,84±2,98	

 (2), de 2,17% a 
4,05%	
Alta	

 667,59±6,03	

 451,90±2,15	

 (2), de 31,37% a 
33,24%	
Prioridades e QoS 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
•  Tempo de Execução de Cloudlets 
Cenário	

 Priorid. Carga	

 LA PDTF (1)	

 LAQ PDTF (2)	

 Melhor	
Grande Homo	

 Baixa	

 682,60±2,10	

 959,60±3,03	

 (1), de 28,42% a 
29,31%	
Normal	

 682,02±1,56	

 654,53±1,49	

 (2), de 3,59% a 
4,47%	
Alta	

 682,65±1,55	

 462,88±1,38	

 (2), de 31,84% a 
32,55%	
Grande Hetero	

 Baixa	

 686,11±1,98	

 965,43±2,73	

 (1), de 28,52% a 
29,34%	
Normal	

 685,18±1,71	

 654,86±1,64	

 (2), de 3,95% a 
4,90%	
Alta	

 685,94±1,74	

 464,05±1,43	

 (2), de 31,97% a 
32,73%	
Prioridades e QoS 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Prioridades e QoS 
•  Inserção de qualidade de serviço não impacta 
significativamente o escalonamento de tarefas 
proposto; 
•  Tempo de execução das cargas de alta prioridade 
reduzido em média em 31%; tempo de execução 
das cargas de baixa prioridade aumentado em média 
em 26%. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Gerência de recursos e serviços compostos 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Computação em Nuvem: nuvem híbrida 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Serviços compostos 
q É possível estabelecer ligações entre os serviços e usá-las em interações 
mais robustas conforme os requisitos dos processos de negócios. 
q Serviços são compostos ou agregados formando aplicações distribuídas que 
envolvem vários participantes. 
q Os serviços podem ser organizandos na forma de workflows. 
q A execução de workflows na nuvem traz novas exigências principalmente no 
que se refere à coordenação e composição dinâmica de processos e 
serviços. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Serviços compostos: workflows 
•  The Montage application created by NASA/IPAC stitches together multiple input images to create custom mosaics 
of the sky. 
•  LIGO's Inspiral Analysis workflow is used to generate and analyze gravitational waveforms from data collected 
during the coalescing of compact binary systems. 
•  The Epigenomics workflow created by the USC Epigenome Center and the Pegasus Team is used to automate 
various operations in genome sequence processing. 
Montage LIGO Epigenomic
s 
https://confluence.pegasus.isi.edu/display/pegasus/WorkflowGenerator 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Middleware para nuvens híbridas 
Bittencourt, L. F. ; Senna, C. R. ; Madeira, E. R. M. . Enabling Execution of Service Workflows in Grid/Cloud Hybrid Systems. In: 
IEEE/IFIP Workshop on Cloud Management, 2010, Osaka, Japan. Network Operations and Management Symposium (NOMS), 
2010. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
GPOL workflow: aplicação do filtro de mediana 
...!
 <gpo:definitions >!
!<gpo:gservices>!
! !<gpo:gsh name="Inst_Zeus-mf1“ !
! ! !uri="http://10.3.77.5:8080/wsrf/services/FactIPService" !
! ! !type="Factory"/>!
! !<gpo:gsh name="Inst_Zeus-mf2"!
! ! !uri="http://10.3.77.5:8080/wsrf/services/FactIPService" !
! ! !type="Factory"/>!
! !<gpo:gsh name="Inst_Cronos-mf2"!
! ! !uri="http://10.3.77.16:8080/wsrf/services/FactIPService" !
! ! !type="Factory"/>!
! !<gpo:gsh name="Inst_Dionisio-mf3”!
 ! ! uri="http://10.3.77.15:8080/wsrf/services/FactIPService" !
! ! !type="Factory"/>!
!</gpo:gservices>!
!...!
 </gpo:definitions>!
!
Para acionar a publicação dinâmica de serviços usar:!
uri="8080/wsrf/services/FactIPService"!
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
GPOL workflow: aplicação do filtro de mediana 
<gpo:process > 
 
 <!--Splits file in 2 parts--> 
 <gpo:invoke name="Inst_Zeus-mf1" method="sliceMatrixToFiles"> 
 <gpo:argument variable="sliceIn" type="string"/> 
 <gpo:return variable="sliceOut" type="string"/> </gpo:invoke> 
 
... <!– Copy slice files from Zeus to Cronos and Dionisio --> 
 
 <gpo:flow name="F_medianFilterMatrix"> <!-- Apply median filter in parallel --> 
 
 <gpo:invoke name="Inst_Cronos-mf2" method="medianFilterMatrix" tagname="cronosMF"> 
 … </gpo:invoke> 
 
 <gpo:invoke name="Inst_Dionisio-mf3" method="medianFilterMatrix" tagname="dioMF"> 
 … </gpo:invoke> 
 </gpo:flow> 
 
... <!– Copy filtered slice files from Cronos and Dionisio to Zeus --> 
!
 <!-- Merge slices files into a new filter file --> 
 <gpo:invoke name="Inst_Zeus-mf1" method="mergeSliceFiles“ tagname=“mergeFiles”> 
 …</gpo:invoke> 
...!
</gpo:process>!
O filtro substitui o valor do ponto pelo valor mediano 
dos seus vizinhos. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Escalonamento em Nuvem 
• Lado do provedor da nuvem 
•  Como otimizar o uso dos recursos computacionais 
•  Minimização do gasto com manutenção e energia 
• Lado do cliente da nuvem 
•  Melhor maneira de utilizar recursos de nuvem privada ou grade 
computacional 
•  Minimizar o custo monetário de execução na nuvem pública 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Escalonamento em Nuvem: usuário 
• Workflow em nuvens híbridas: 
•  Usuário quer utilizar seus recursos locais disponíveis (“gratuitos”) 
e, quando necessário, alugar recursos pagos de uma nuvem IaaS. 
•  Tempo de execução desejado (deadline) para o workflow → 
recursos locais podem não ser suficientes. 
•  Decisão: quais tarefas do workflow devem ser enviadas para a 
nuvem pública de modo a obedecer o deadline e minimizar os 
custos monetários? 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Escalonamento em Nuvem: usuário 
1.  Escalonar workflow nos recursos locais 
2.  Enquanto makespan > Deadline 
1.  Selecionar nó N de acordo com política de seleção de nós 
2.  Selecionar recurso da nuvem pública de acordo com política de minimização de 
custos 
3.  Escalonar nó N na nuvem pública 
Bittencourt, L. F.; Madeira, E. R. M.. HCOC: a cost optimization algorithm for workflow scheduling in hybrid clouds. Journal of 
Internet Services and Applications, 2011. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Escalonamento em Nuvem: usuário 
BITTENCOURT, L. F. ; MADEIRA, E. R. M. ; FONSECA, N. L. S . Scheduling in Hybrid Clouds. IEEE Communications 
Magazine (Print), v. 50, p. 42-47, 2012. 
Prof. Luiz Fernando Bittencourt IC - UNICAMP 
Escalonamento em Nuvem: provedor SaaS 
•  Provedor de nuvem SaaS provê 
serviço de execução de workflows aos 
usuários. 
•  Provedor SaaS utiliza recursos 
alugados de múltiplos provedores 
IaaS. 
•  SLAs em dois níveis: 
•  Usuário e SaaS (deadline) 
•  SaaS e IaaSs (aluguel de recursos) 
•  Recursos alugados dos IaaSs podem 
ser reservados ou sob demanda. 
•  Reservados: pagamento inicial + 
pagamento por tempo de uso. 
•  Sob demanda: apenas pagamento 
pelo uso, porém mais caro. 
GENEZ, T. A. L. ; BITTENCOURT, L. F. ; MADEIRA, E. R. M. . Workflow Scheduling for SaaS / PaaS Cloud Providers 
Considering